Integration of an online payment API
Collection unlocks the service, not an internal ticket
Our team wires your payment provider into the product: entitlements, subscriptions, payouts, disputes. Checkout is only the start of the flow.
- Payment connectors in production
- flow model scoped
- idempotent webhooks
What is an online payment API and when should you have it integrated?
An online payment API lets your application trigger a collection, follow its outcome and react to what happens next: a failed payment, a refund, a dispute. Off-the-shelf modules cover a simple sale. You have a custom integration built when money moves between several parties, when billing follows a cycle with trials, tiers and proration, or when collection must open rights in your product and land cleanly in accounting.
The payment solutions we integrate
Stripe
The most complete. Collection, subscriptions, marketplaces and payouts.
PayPal
A payment method your buyers already know, often as a complement.
SumUp
In-person collection, when the sale closes in the field.
GoCardless
Recurring SEPA Direct Debit, for subscriptions and instalment plans.
Mollie
The European option, with the local payment methods of your markets.
What the payment provider does not do on its own
The checkout module collects money. The rest (rights, payouts, books) still has to be built in your application.
I do not know who paid for what
We attach every collection to its invoice and its customer in your tool, with a reference carried end to end rather than a guessed reconciliation.
A customer pays and still has no access
The payment event opens rights immediately, and a failed payment restricts them. No more manual step between settlement and the service delivered.
Payouts to sellers are a headache
We wire the split and the fee as the money moves, with edge cases handled: cancelled order, partial refund, seller balance too low.
My accounting never adds up
Collections, fees, refunds and charges are pushed with the right split into your accounting, and a periodic check flags any gap.
What each solution actually involves
GoCardless
SEPA Direct DebitSEPA Direct Debit, a fit for B2B subscriptions and instalment plans where card fees become hard to justify. The integration topic is the mandate lifecycle and how rejections are handled, not the transaction: a rejected debit must trigger an action, not silence.
- Mandates and schedules driven
- Cost suited to high amounts
- Rejections treated as a nominal case
Mollie
European optionThe European option, useful when your markets expect their local payment methods and an international catalogue is not enough. The integration is judged on the real coverage of the methods you need, market by market, rather than on the length of the announced catalogue.
- Local payment methods
- Coverage to check market by market
- A credible alternative in Europe
PayPal
Buyer reflexA payment method your buyers recognise, which weighs on conversion in consumer sales. It is most often added to a primary provider rather than replacing it, and the integration is then designed as a second flow to reconcile, not as a second system.
- Purchase reflex on the buyer side
- Comes as a complement to a primary provider
- A flow to reconcile with the rest
Stripe
The most completeThe most complete platform, and the one that goes furthest when money moves between several parties or when billing follows a cycle. In return, the structural decisions are taken early: who owns disputes, who pays the fees, which flow model. Changing them later costs a full rewrite.
- Marketplaces and fees in the flow
- Subscriptions, trials and proration handled
- Test clocks to simulate the future
SumUp
In-person salesIn-person collection, on a terminal, when the sale closes in a shop, on a round or on a site. The integration challenge is not the payment itself but its return into your business software, so a field sale exists on the same footing as an online sale.
- Face-to-face collection
- Field sales pushed into the tool
- Same treatment as online sales
Four flow architectures we wire
Invoice state, product state
Trial, tier, proration and failed payment become business states. Features open and close without a dashboard kept by hand.
Marketplace at capture
Commission and seller shares are computed in the flow, including partial refunds and insufficient balance, not as a month-end recharge.
Internal multi-provider layer
Stripe, a card complement, a direct debit: one payment model in the product. Adding a method does not duplicate billing.
Failed-payment sequence in the app
Failure, reminder, restriction: dunning lives in the product. Collections become a measurable queue, not a mailbox.
Who gains, and what we decide with you
We do not pick a provider in the abstract. We scope the flow model with product, finance and ops.
Product treats access as a state
Product and CS stop unlocking accounts by hand. We make the payment event the source of entitlement.
Finance reads three amounts, not a net
Collected, paid out, taken as fees: the CFO and the accountant see the split. We push it as-is into the books.
Marketplace ops stop arbitrating by hand
Cancellation, dispute, seller balance: edge cases are rules, not tickets. We write them with you at scoping.
Collections leave the inbox
Each failure has an age, an owner, a next action. We wire that queue to the provider, not the other way around.
Stripe collection running in production
The method a payment flow forces
Flow model
Sale, subscription or marketplace. Merchant, disputes, fees: decided before code.
Deliverable: flow model mapIdempotency and 3DS
Idempotency, isolated secrets, 3DS path designed in the tunnel.
Deliverable: idempotency contractWebhook acceptance
Signature, queue, out-of-order replay. Decline, refund, dispute before cutover.
Deliverable: replayable webhook suiteDispute operations
Dispute, representment, reversing entry: the flow lives after capture.
Deliverable: dispute runbookWhat nobody tells you before you sign
A poorly handled webhook costs money
With most providers, the outcome of a payment arrives as an event. If your server does not respond correctly, you do not lose a message: you lose the trace of a collection, and sometimes you delay an entire billing cycle.
Events arrive out of order and twice
No serious provider guarantees delivery order. Logic that assumes a sequence is wrong by construction: you must deduplicate, and reread the object concerned when an event arrives early.
Strong customer authentication breaks overly optimistic journeys
A share of payments asks the cardholder for an extra confirmation. This is not an error to recover from, it is a step to design into the journey, or you ship with an unexplained failure rate.
Changing the flow model costs a full rewrite
Who appears as the merchant, who owns disputes, who pays the fees: these choices structure the code and the accounting. They are settled during scoping, with your finance team, not six months later.
What we measure on a payment project
Online payment API integration: your questions
Three steps. First choose the flow model: a simple sale, a subscription, or money moving between several parties. Then build the connector on the server side, with an idempotency key on every create so a replay never produces a second payment, and secrets isolated from application code. Finally handle events correctly: verify the signature, respond immediately, do the work in a queue, deduplicate. The sensitive part is never the payment call, it is what happens after: failed payment, refund, dispute, and the return of all of that into accounting.
It depends on the flow model far more than on the provider you pick. A simple collection with an email confirmation costs far less than a subscription with tiers and proration, and far less still than a marketplace where money is split across several sellers. The real cost hides in the edge cases: an order cancelled after payout, a partial refund, a dispute opened two months later, a gap between the provider and accounting. We scope the perimeter up front and give a firm estimate.
It is decided on three criteria, in that order. The business model first: a simple sale, a subscription, or payouts to third parties, the last of which sharply reduces the number of credible options. The payment methods your customers expect next, which depend on your markets and on whether buyers are consumers or businesses. Cost last, looking at average amount and recurrence rather than the advertised percentage: on high B2B invoices, direct debit beats the card. Tell us your model, we will tell you what it implies.
Yes, and it is common: a primary provider, a complementary method for conversion, sometimes a direct debit for subscriptions. The difficulty is not wiring them up, it is keeping a single truth on the product side. We put an internal payment model that is independent of the provider, where every incoming flow is normalised before it reaches your business logic. Without that layer, each extra payment method duplicates billing and accounting logic, and the gaps start.
By pushing the flows with the right split rather than a net amount. A collection, the provider fee, a possible payout to a third party and a refund are four different entries, and aggregating them loses the information at the moment the accountant needs it. We build the flow into your accounting tool, then a periodic consistency check between what the provider exposes and what accounting records, with an alert on a gap rather than a silent correction. An entry is not repaired behind the accountant's back.
What is your flow model?
Simple sale, subscription or marketplace: 30 minutes to pin it down, and to tell you what it implies for the provider, 3DS and the books.
Discuss my payment project