PSP route: regulation + a cut
Owning funds flow drags in money-transmitter / PSP obligations, and the interchange cut scales with the money your customers move — not with the value you add.
B2B SaaS billing add-on
Ship “pay this invoice” without becoming a PSP.
Add native SEPA, ACH, Faster Payments, Pix, or Swiss QR-bill output to your vertical-SaaS platform — whichever is region-appropriate for the customer — without absorbing PSP regulation or a 2–3% interchange cut. JSON in, bank-accepted XML out. Your customer’s corporate bank stays in place; you never sit in the funds flow.
The problem
Two bad options for an in-product “pay” button.
Your customers want to pay and collect from inside your product. The usual paths both have a tax. Integrate a PSP and you take a 2–3% interchange cut against payments that already have a bank rail — and you start touching funds flow, which drags in regulation you never wanted. Build the ISO 20022 emitter yourself and you own the XSD envelopes, the per-region message types, the per-bank overlays, the ASCII-fold rules, and the Nov-14-2026 structured-address mandate — for a file format that is not your product.
DIY route: a standing tax
SEPA, ACH, Faster Payments, Pix, and QR-bill each have their own schema, overlays, and mandates to track. That is a permanent engineering line item on a non-core surface.
Both delay the feature
A PSP integration is a contract negotiation; a DIY emitter is a quarter of work. Either way the “pay” button you promised on the roadmap slips.
How iso-compliant solves it
Pure infrastructure: JSON in, bank XML out.
iso-compliant is the file-shaping layer, not a PSP. You send a clean JSON payload and receive bank-accepted XML — or a Swiss QR-bill — region-appropriate to the customer, validated against the relevant rule pack. The customer’s corporate bank stays in place; the file moves through their channel. You ship the feature in days, not a quarter, and you never take an interchange cut or touch the money.
Map your invoice to our JSON
Your platform already holds the invoice — payer, payee IBAN, amount, currency, reference. Map it to the structured payload. The same shape covers SEPA credit transfer (pain.001), direct debit (pain.008), and Swiss QR-bill; region-appropriate output is a parameter, not a rewrite.
Get bank-accepted XML (or a QR-bill) back
POST the payload, receive XSD-valid XML — or a Swiss QR-bill payload — validated against the relevant rule pack. No envelope-template hunting, no per-bank overlay maintenance on your side. The deterministic path keeps it fast enough to sit inside a user-facing request.
Your customer submits via their own bank
The file goes to your customer’s existing corporate bank through their channel — you never touch the funds. That is the whole point: no PSP licence, no money-transmitter registration, no interchange. You ship a feature; the bank relationship stays where it belongs.
Why this is not a PSP
We do not hold funds, we do not hold your customer’s bank credentials, and we do not move money. We emit a file that your customer submits through their own bank relationship. That distinction is what keeps you — and us — out of PSP regulation and out of the interchange chain. We are infrastructure, billed per document.
What you integrate
Embed in days. One API, every region.
A single JSON contract spans the message types; the region is a parameter. Start free with the QR-bill endpoint, then add SEPA / ACH / Faster Payments output as your customers’ regions demand — no new integration each time.
- •
POST /v1/iso20022/pain.001/pain.008for SEPA / ACH / Faster Payments output. - •The free QR-bill endpoint to ship Swiss output on day one.
- •Structured-address validation built in, so embedded output is already compliant with the Nov-14 mandate.
Embed in days
Ship the “pay” button without the licence.
100 documents per month free, no card. Start with QR-bill, add SEPA / ACH / Faster Payments as your regions grow — one integration, the customer’s bank stays in place.