Payment integration is often treated as an engineering task. Pick a gateway, follow the docs, connect the API, done.
The connection is usually the easy part. The hard parts are product decisions that nobody wrote down: which methods to offer in which country, what the user sees when a payment fails, what happens if they click pay twice, and how finance finds out what actually happened.
At Travelxp I worked on integrations with payment gateways for both subscription streaming and travel booking, across a lot of countries. These are the decisions I'd want settled before the build starts.
Which methods, in which markets
Cards aren't the default everywhere. Depending on the country, people may expect wallets, bank transfers, local payment schemes or app store billing.
| Question | Why it matters |
|---|---|
| What do people in this market usually pay with? | Missing the common method loses buyers quietly |
| Which currencies will you show and charge in? | Currency conversion surprises cause abandonment and disputes |
| Do you need more than one gateway? | Coverage, cost and backup if one fails |
| Are app store rules involved? | Subscriptions inside mobile and TV apps may need store billing |
I'd look at checkout drop-off by country before and after adding a method. That's usually the clearest signal of whether it helped.
Design for failure, because it's common
Payments fail for lots of reasons: insufficient funds, a bank declining the transaction, an authentication step not completed, a timeout between systems. These aren't edge cases. They happen every day.
Decide what the user sees for each broad type:
- Declined: a clear message and an easy way to try another method.
- Authentication not completed: a way to retry without re-entering everything.
- Timeout or unknown status: don't tell the user it failed if you don't know. Check the status before asking them to pay again.
That last one matters. If the system shows an error and the payment actually went through, the user may pay twice.
Prevent duplicate charges
Users double-click, refresh, and hit back. Networks drop. The system needs a way to recognise that two requests are the same attempt.
Stripe's documentation on idempotent requests explains the general idea: send a unique key with each payment attempt so a retry doesn't create a second charge. 1 Most gateways have some equivalent. As a PM, I don't need to implement it, but I do need to make sure it's in the requirements.
Subscription renewals need a recovery plan
For subscriptions, a failed renewal doesn't necessarily mean the customer wants to leave. Cards expire. Banks block transactions. A sensible retry schedule, plus a clear message asking the user to update their details, can recover a lot of these.
Decide how long someone keeps access while you retry, and what they see. Cutting them off immediately is harsh. Letting it run forever costs money.
Refunds and reconciliation
Finance needs to match what the gateway says happened with what your system says happened. If those disagree, someone has to investigate manually, often days later.
Make sure you have:
- A clear record of each payment attempt and its final status.
- Webhooks or regular checks so your system learns about status changes it didn't initiate, like refunds or chargebacks.
- A defined refund flow, including partial refunds if the product needs them.
For travel bookings this gets harder, because the payment, the supplier booking and the confirmation are separate steps that can fail independently. I wrote more about that sequence in the travel checkout post.
Track it by gateway and method
Payment success rate should be broken down by gateway, method, country and platform. An overall rate can look fine while one gateway in one country is quietly failing.
The best payment experience is one users don't notice. Getting there takes a surprising number of product decisions, and most of them are about what happens when things go wrong.