Taking payments in Switzerland: the decisions that come before the code

Most payment integrations we are asked to review work. They accept money, they reconcile, and the finance team has stopped complaining. They are also, quite often, about to be rebuilt — not because the code is bad, but because a decision taken in the first week made the second year expensive.

The decisions that matter are not technical. They are about who holds the money, who holds the customer relationship, and what happens the first time a payment fails in a way nobody planned for.

Who is actually holding the money?

Between a customer paying and the funds landing in your account, someone is holding that money. In a straightforward card integration it is the acquirer, briefly. In a marketplace or platform model — where you collect on behalf of someone else and pay them later — it may be you, and that is a materially different business.

Holding funds for third parties in Switzerland can bring you into scope for financial market regulation. The threshold questions are whether the funds are yours, how long you hold them, and whether you have discretion over them. This is a supervisory question rather than an engineering one, and the Swiss Financial Market Supervisory Authority publishes the guidance that governs it.

Companies that discover this in year two do not usually discover it gently. They discover it because a bank asks a question during an account review, or because an investor's legal counsel asks it during diligence.

What does the QR-bill actually change?

The QR-bill replaced the old Swiss payment slip and made structured references the default rather than an option. Practically, that means reconciliation can be automatic — if you generate references correctly from the start.

The structured creditor reference is the whole point. When an invoice carries one, the incoming payment file tells your system exactly which invoice was paid, without a human matching amounts to names. When it does not, someone matches amounts to names. That someone costs more every year and is wrong more often than anyone admits.

The specification is published by SIX, which operates Swiss payment infrastructure. Read it before designing your invoice numbering, because your invoice numbering has to fit it, not the other way round.

Cards, bank transfer, or both?

For most Swiss SMEs selling to other businesses, bank transfer against an invoice remains the dominant method and cards are a convenience. For consumer-facing businesses the balance reverses. The mistake is building for one and bolting on the other, because the two have different failure modes and different reconciliation paths.

The row that surprises people is the failure mode. A declined card is loud: the customer sees it and usually tries again. A transfer that never arrives is silent, and a silent failure is only found by whoever is watching the ledger. If nobody is watching the ledger daily, build that before you build anything else.

Where the integrations actually break

Three patterns account for most of the rebuilds we see.

The provider became the system of record. Refunds, partial payments and credit notes were handled in the provider's dashboard because it was quicker, so the truth about what a customer owes now lives outside your own systems. Migrating away means reconstructing history from an export.

Currency was treated as a formatting problem. CHF, EUR and the occasional USD were stored in one column with a separate currency field added later. Every report since has needed a caveat.

Nobody modelled the reversal. The happy path was built well; the refund, the partial refund, the refund after a partial payment, and the chargeback were added one at a time under pressure. This is the same failure we describe in ERP data migration: what actually goes wrong — the exceptions are the system, and treating them as edge cases is what makes them expensive.

Our financial technology practice starts these engagements by modelling money movement end to end, including every reversal, before discussing providers. The model usually eliminates half the shortlist on its own.

What to do before choosing a provider

Write down, on one page: who holds the funds and for how long; which currencies you will accept in the next three years; what a refund does to your ledger; and who looks at unmatched payments, daily, by name. That page is worth more than a provider comparison, because it is what makes a provider comparison answerable.

For firms in financial services there is a further step: confirm early whether your model brings you into supervisory scope, because that answer changes the architecture rather than the vendor. The cost of asking is a conversation. The cost of not asking is discovering it during diligence.

Related reading

• Cloud migration in Swiss banking after the revised FADP
• The revised FADP: what Swiss companies actually have to do
• Financial technology consulting