Approval rates, retries, failure messages, fees and reconciliation shape revenue and customer trust directly. That makes payments a product area with an owner, metrics and a roadmap.
Most companies make their payments decision once, during a sprint, usually when an engineer picks whichever provider had the friendliest documentation. Then nobody owns it again until something breaks. That is a strange way to treat the step where every unit of revenue either arrives or does not. Approval rates, the methods you offer, how you retry, what a failed customer sees, what you pay in fees and how long finance takes to reconcile all shape revenue and customer experience directly. They need a product owner, with metrics and a roadmap, like any other part of the product that touches money.
Treating payments as plumbing means asking one question: does it work? A checkout that processes most cards passes that test, and the test hides the questions that matter. What share of legitimate customers are declined? Which markets cost more than they should because of cross-border processing? How many support tickets are about charges customers do not recognise? How many hours does finance spend each month matching payouts to orders?
None of these show up as an outage, so none of them get a ticket. They show up as slightly lower conversion, slightly more churn, slightly more support load and a finance team that quietly dreads month end. Each is small on its own. Together they are often worth more than the feature the team is currently shipping. Having founded and run a payment orchestration company, I have found that most of this sits in plain view once someone is asked to look.
A payments owner needs a short set of numbers, reviewed monthly and segmented enough to be useful. Averages are where payment problems hide.
"Payment failed" is the most expensive phrase in a checkout, because it treats very different events as the same. A decline can mean insufficient funds, an expired or reported card, an issuer that suspects fraud, an authentication challenge the customer abandoned, a timeout between systems, a transaction type the issuer will not accept, or your own fraud rules rejecting someone. Each needs a different response.
Some declines are hard: retrying will not help and may hurt, as with a stolen card or a closed account. Some are soft: a timeout, a temporary issuer problem, funds that may clear after payday. Some are not declines at all but friction, such as an authentication step that confused the customer. If your system and reports collapse these into one bucket, you cannot fix any of them. The first useful piece of payments work in most companies is simply grouping decline reasons into categories and looking at the distribution by market and method.
The customer-facing message matters just as much. "Your payment could not be processed" leaves people guessing. You should not reveal fraud logic, but you can say "your bank declined this payment, try another card or contact your bank" or "we could not reach your bank, nothing was charged, please try again". The second message alone prevents a lot of anxious repeat attempts.
Retries are where payments engineering meets customer trust. Done well, they recover revenue that would otherwise be lost: a timeout retried once, a subscription charge retried after a few days, a soft decline sent to a second provider. Done badly, they charge someone twice.
A double charge does more damage than a lost sale. The customer sees two debits, assumes you are careless or worse, contacts support, and often disputes one charge with their bank, which costs you a fee and counts against your dispute ratio. Even when the second authorization is only a hold that drops off later, the customer cannot tell the difference and should not have to.
The rules are well understood, even if they are not always followed. Every payment attempt carries an idempotency key tied to the order, so the same request sent twice produces one charge. After a timeout, check the status of the original attempt before retrying instead of assuming it failed. Never retry hard declines. Run recurring retries on a deliberate schedule that respects issuer rules and likely pay cycles, rather than hitting the card daily. And show a clear processing state in the interface, so nobody clicks Pay again because the button looked frozen.
Most companies send all their payments through a single provider. That is a reasonable start: one integration, one contract, one dashboard. It becomes a risk as volume grows. An outage stops your revenue for its duration. A risk review on the provider's side can hold payouts or close an account at short notice. And one provider may be strong in some markets and weak in others, which you only discover if you can compare.
The trade-off is real. A second provider costs engineering time, complicates reconciliation, splits volume (which can weaken your negotiating position with each), and adds surface for bugs. For an early company with modest volume in one market, one well-chosen provider is usually the right call. Concentration becomes the larger risk roughly when a few hours of outage would be a board conversation, or when you sell in markets where local methods and local acquiring clearly outperform your current setup. Before that point, at least keep payment logic behind your own internal interface, so adding a provider later is a project and not a rewrite.
Payments are only as good as your ability to explain them afterwards. When a customer says "you charged me twice" or "the payment failed but money left my account", a support agent should be able to see every attempt for that order in one place: amount, method, provider, time, the response in plain language, and current status. If that requires an engineer to search logs, every payment question becomes an escalation.
Finance needs the same thing in a different shape: the ability to trace one payout on the bank statement back to the orders, fees, refunds and disputes inside it. In regulated environments, where I have spent a good part of my career, this is also an audit matter. If you cannot reconstruct what happened to a payment, you cannot evidence your controls. Designing for explainability means keeping your own record of each attempt with a consistent internal status model, rather than treating each provider's dashboard as the source of truth.
Take a hypothetical subscription software company selling to small businesses in several countries and billing monthly by card. The dashboard shows a decent overall approval rate, so nobody looks further.
A product owner asked to review payments starts by segmenting. Approvals in one newer market turn out to be clearly lower than at home, with most failures being generic declines from local issuers. Failed recurring charges are retried daily for a week and then the subscription is cancelled, while the failure email just says the payment failed and links to the billing page. Support tags show a steady trickle of "charged twice" tickets that trace back to customers clicking Pay again during slow authentication.
The resulting roadmap is small and specific: test local acquiring or a locally preferred method in the weak market, move to fewer recurring retries timed around common pay dates, rewrite failure messages by decline category, add idempotency checks and a visible processing state, and give support a single payment timeline per order. None of it is glamorous, and all of it can be measured against the metrics above.
If you take a small number of large payments by bank transfer under negotiated contracts, most of this matters less. Your payments problem is invoicing and collections, not authorization rates. The same holds at very low volume, where a dedicated owner would cost more than the leakage they could recover. In those cases pick a sensible default and revisit it when card or wallet volume becomes material, and be honest about when that happens, because it tends to happen quietly.
Pick one person and give them these numbers, a monthly review and the authority to change checkout, retry logic and provider setup. You do not need a payments team to start, only an owner. The first review often pays for the role, because the problems were never really hidden, just unassigned.
Written by
Ratomir Jovanovic
In collections and payments, the conversation design is the compliance work. How to set guardrails on promises, detect vulnerability, keep audit trails and measure outcomes that matter more than containment.
27 August 2026
Most LLM features that disappoint in production were judged badly, not built badly. A practical evaluation process for product leaders: job definition, golden sets, failure taxonomy, budgets and a ship/no-ship rule.
8 July 2026
A product leader can now put a working prototype in front of users in days. The long PRD should shrink to a decision memo plus a prototype, with clear rules on what the prototype proves and what it does not.
9 June 2026