A merchant-of-record service sells the product for you and takes on VAT; the broker holds one answer to who is allowed to use what.
A merchant of record service sells the product in your place and takes on VAT in every country. Payment Broker sits between it and your applications and holds one answer to the question of who is allowed to use what.
A business that bills a digital product outside Serbia, by subscription, and does not want to run VAT filings by country. If you have several products that share the same users, the gain is larger — one record instead of three. For one product, one country, and a one-time charge, this is too much.
Payment Broker is a service that connects your applications to merchant-of-record providers — Paddle and Polar. They take on billing, VAT, and refunds in every country, and the broker receives their messages, keeps a local record of subscriptions and credits, and gives applications one answer to which rights which account has.
The payment window is rendered by the provider, so the card number never goes through your server or your responsibility.
The signature is checked over raw bytes before processing; the message is written first and only then processed — if processing fails, it is retried.
Instead of trusting the message contents, the broker asks what the state is now. That is why messages that arrive out of order do not roll a subscription backward.
Applications do not talk to the provider. They ask the broker which rights an account has and get the same answer.
The merchant of record is the seller before the law. Registration, filing, and VAT payment go in their name, in over a hundred markets.
Who has which package, until when, and with how many credits — one answer for all your products.
Monthly packages, one-time top-ups, and usage billing go through the same flow and the same records.
Messages are written before processing and retried until they succeed — a service outage does not mean a lost subscription.
Cancellation, card change, and invoice download happen on the provider’s page. You do not build those screens.
Providers sit behind a shared interface, so a change or an addition does not touch the applications.
The provider charges a percentage per transaction — Paddle 5% + $0.50, Polar from 5% + $0.50 downward with volume. Integrating the broker with your application is estimated by scope: number of products, packages, and whether usage is billed.
Both are merchant of record services. That means that in front of the customer and the tax authority the seller is not your company but them — you sell to them, they sell to the customer.
A digital product is taxed by the customer’s country. Selling in twenty countries means twenty sets of VAT rules, thresholds, and filings. The merchant of record takes that obligation in its own name.
Billing for subscriptions and one-time purchases, built-in checkout, invoices, fraud and refund handling. The fee is 5% + $0.50 per transaction, with no monthly subscription — tax registration, filing, and remittance are included.
A newer service oriented toward software and AI products. Besides subscriptions it also meters usage — API calls, tokens, storage — and runs prepaid credits that get spent. The fee starts at 5% + $0.50 and falls with volume.
They don’t know what your product is allowed to do. They know someone paid for a plan — but whether that account may open a fifth site or spend another thousand credits is your question. That’s where the broker comes in.
The whole flow is built so that nothing depends on one successful HTTP call — nor on the order in which messages arrive.
The customer doesn’t go anywhere. The payment window is rendered by the provider itself, so the card number never passes through your server — and thus never through your responsibility.
Every change arrives as a signed message. The signature is verified over the raw bytes of the message, before anyone reads it, so a fake message doesn’t enter the system.
Messages are written first, then processed. If processing fails or the service goes down, the message is still there and is retried — a subscription isn’t lost because the server was busy.
Instead of trusting the message contents, the broker asks the provider what the state is now. That’s why messages that arrive in the wrong order cannot roll a subscription back to an old state.
Applications don’t talk to Paddle or Polar. They ask the broker what rights an account has and get one answer — the same for all applications.
Billing looks like a small job until the first disputed case starts — a double charge, a cancellation mid-period, a refund after a month.
Monthly plans and one-time credit top-ups go through the same flow, with the same records.
The broker runs multiple products at once — each with its own plans and prices, without a dedicated service per application.
The customer does that on the provider’s page. You don’t build billing screens and you don’t hold card data.
The same message can arrive twice — providers do that when they aren’t sure the first was received. The broker recognizes it and doesn’t charge twice.
On startup the service refuses to run if it was given test keys in production, or the other way around. That’s a bug that otherwise is only discovered when someone can’t pay.
From the outside, only the address the provider sends messages to is available. Everything else talks inside the network, with a token.
If you sell one product in one country and have ten customers, this is too much. It is worth it when at least some of the following apply.
There’s nothing exotic — that’s the point. A system that bills must not be a place for experiments.
Answers about Payment Broker from Devizzo.
Tell us what you sell and in which countries — we’ll say whether you need a merchant of record, which provider is better for your case, and what it means to connect that to your application.
Describe your case