Payment Integration: The Decisions That Matter Before You Write Code
Payment integration looks like a technical task. The decisions that cost you money are commercial and made before any code is written.
Every payment provider makes integration look trivial in the documentation, and for the happy path it genuinely is. The cost lands elsewhere: in fee structures, failed payments, disputes and the compliance scope you accepted without noticing.
Hosted or embedded checkout
A hosted checkout — where the customer is redirected to the provider — keeps card data entirely off your systems and reduces your PCI compliance burden to the simplest tier. An embedded checkout keeps the customer on your site and converts slightly better, and with modern provider-hosted fields it does not necessarily expand your compliance scope. Choose deliberately, and be sure you know which category your implementation falls into.
The fees nobody quotes
- Cross-border and currency conversion fees, which can double the headline rate on international sales.
- Dispute fees, charged per chargeback whether or not you win it.
- Payout timing, which is a cash flow decision as much as a cost one.
- Refund handling: some providers keep the original processing fee even after a full refund.
Failed payments are a growth problem
For anything recurring, involuntary churn from expired cards and declined charges is frequently larger than customers actively cancelling. Retry logic timed around paydays, card updater services, and a clear pre-dunning email recover a meaningful share of that revenue — and it is revenue you already earned once. These are the decisions we settle in discovery before quoting a custom web application.
Before you go live
- Test the failure paths, not just success: declines, timeouts, duplicate submissions, and the customer closing the tab mid-payment.
- Make the flow idempotent so a retried request never charges twice.
- Log every state transition. Payment disputes are argued with evidence, and 'we think it succeeded' is not evidence.
- Decide your refund policy and encode it before the first refund request, not during it.
- 2 checkout models, chosen deliberately
- idempotent every payment request
- involuntary churn often larger than voluntary
Frequently asked questions
Should we support multiple payment providers?
Rarely at first — the maintenance and reconciliation cost is real. It becomes worthwhile at high volume for redundancy, or when a specific market's preferred local payment method is not supported by your primary provider.
Do we need to store card details for repeat purchases?
You should not store them yourself. Every serious provider offers tokenisation: they keep the card, you keep a token. This gives you one-click repeat purchases with none of the storage liability.
More on this topic: Web & Product.
Keep reading
Want this built for your business? See what we do.