The payment processor decision record: why the payment provider you chose determines your dispute rate ceiling and your cross-border revenue capture

A 14-person developer-tools SaaS built their checkout in 2022. The founding engineer followed a Stripe quickstart tutorial, copied the server-side charge creation code, connected Stripe.js for the card element, and verified that a test charge succeeded. The tutorial was clear and the integration was fast — the first real payment processed within a week of starting the integration work. The code used stripe.charges.create() on the server and stripe.createToken() on the client. This is the Stripe Charges API, which predates Payment Intents. The tutorial being followed was written in 2018.

By 2025 the product had significant European revenue — 41% of monthly recurring revenue from customers in EU member states, UK, and Switzerland. The founding engineer had left the company two years earlier. No one on the current team knew which Stripe API the integration used; the Stripe SDK was a dependency in package.json and the checkout form worked. What the team did notice was that their dispute rate on European transactions was 1.1% — against a US dispute rate of 0.3%. Stripe's Radar dashboard showed the European disputes were primarily unauthorized transaction claims: cardholders stating they had not authorized a charge. The team assumed this was a fraud problem and added Stripe Radar machine learning rules to block suspicious cards. The dispute rate improved marginally — to 0.9% on EU transactions — but remained elevated.

A payments consultant hired to investigate identified the root cause in 30 minutes. The integration used the Charges API. Under PSD2's Strong Customer Authentication requirements, card issuers in the European Economic Area are permitted to decline charges that do not include a completed 3DS challenge for authentication. When a Charges API integration processes a European card without triggering 3DS, three outcomes are possible: the issuer approves the charge anyway (common for cards issued by banks with loose SCA enforcement), the issuer declines the charge (which the team was seeing as failed payments), or the issuer approves the charge but classifies it as a non-authenticated transaction — meaning that if the cardholder later disputes it as unauthorized, the liability for the disputed amount falls entirely on the merchant rather than shifting to the card-issuing bank. The unauthorized transaction disputes the team was receiving were precisely this third category: charges that went through, but which the issuing bank had not authenticated via 3DS, so the bank sided with the cardholder on every dispute and the merchant bore the loss. The Charges API did not fail to process the payment — it failed to authenticate it in a way that would have protected the merchant.

The migration from Charges API to Payment Intents API took six weeks. Every server-side charge creation call was rewritten from stripe.charges.create() to stripe.paymentIntents.create() and stripe.paymentIntents.confirm(). Every client-side payment form was updated to use stripe.confirmCardPayment() rather than stripe.createToken() followed by a server-side charge. Every webhook handler was rewritten from charge.succeeded to payment_intent.succeeded. Subscription flows with trial periods, mid-cycle upgrades, and failed payment retry logic each required separate analysis. Six weeks of engineering time on a team of four billing-adjacent engineers, three years after the Charges API was chosen. The API choice was never documented — not in a decision record, not in a technical spec, not in a comment in the integration code. The selection rationale was "the tutorial used this API." See the pattern in decisions never written down.

The second incident was about money, not liability. A nine-person B2B SaaS product launched in the US in 2023 with Stripe, standard 2.9% + $0.30 pricing, settling in USD. The founding team was US-based; their initial customers were US-based. Eighteen months later, word-of-mouth spread into the UK and EU developer community. By the time the CEO ran the annual revenue model, 38% of MRR was coming from non-US customers — customers paying with cards issued by UK and EU banks. Stripe's standard pricing adds a 1.5% cross-border fee for cards issued outside the domestic settlement region. A card issued by Barclays in the UK processed against a USD-settling Stripe account carries the standard 2.9% + $0.30 plus the 1.5% cross-border fee, for an effective processing rate of 4.4% plus the fixed component.

At $85k MRR with 38% international revenue ($32,300/month from non-US cards), the cross-border fee alone was $485/month — $5,820 per year in fees that the original pricing model had not included. The CEO asked whether switching to Adyen would reduce this. Adyen offers local acquiring in 40+ countries: a UK card processed through Adyen's UK acquiring license is a domestic transaction for fee purposes, eliminating the cross-border component. Adyen's interchange-plus pricing would bring the effective rate from 4.4% to approximately 1.8% on UK transactions. The problem was Adyen's minimum volume requirement: Adyen's standard contract requires approximately $1 million per month in processing volume before they will negotiate interchange-plus pricing. The company was processing $85k per month. Adyen was not an option yet. The alternative — switching to Paddle as Merchant of Record — would eliminate cross-border fees entirely, because Paddle processes the transaction locally in each customer's country. But Paddle's fee is 5% + $0.50, higher than Stripe's 4.4% effective rate on UK cards. And switching to Paddle would require renegotiating or migrating every existing subscription, notifying existing customers of the billing provider change, and reworking the tax accounting setup. The cross-border fee structure had been locked in at launch. The decision that set it — "use Stripe" — was never compared against the cross-border fee model or the international revenue projection.

The four structural properties that payment processor selection determines

When teams choose a payment processor, the evaluation focuses on integration ease (which PSP has the best developer documentation?), pricing headline rate (2.9% + $0.30 is the market reference), and time to first working charge. These are legitimate criteria. The structural properties that determine whether the selection ages well — whether disputed European transactions carry SCA liability shift, whether the effective rate on international revenue is 2.9% or 4.4%, whether VAT compliance creates a quarterly obligation in 30 countries, and whether the product can ever split payments to third parties — are set at selection time and are almost never revisited until one of them produces an incident.

SCA compliance model and liability allocation. Under the EU's Payment Services Directive 2 (PSD2), strong customer authentication is required for most card payments to customers in the European Economic Area. The authentication mechanism for cards is 3D Secure (3DS). When 3DS is completed — the cardholder authenticates via a biometric or one-time code through their bank's flow — liability for unauthorized transaction disputes shifts from the merchant to the card-issuing bank. When 3DS is not completed (either because it wasn't triggered, or because the cardholder abandoned the challenge), liability stays with the merchant. The PSP integration method determines whether 3DS is triggered automatically for cards that require it, or whether 3DS must be triggered explicitly, or whether it is not available in the integration path at all. Stripe Payment Intents with Stripe.js: 3DS is triggered automatically when the card issuer requires it. Stripe Charges API with createToken: 3DS is not triggered. Custom card form integrations that collect and transmit raw card numbers directly to the PSP (non-PCI DSS compliant in most configurations) bypass both Stripe's SCA handling and PCI DSS scope controls simultaneously.

The liability allocation consequence is not theoretical. An unauthorized transaction dispute under PSD2 on a non-3DS-authenticated charge is almost always decided in the cardholder's favor by the card-issuing bank, because the bank did not authenticate the transaction and cannot verify the cardholder authorized it. On a 3DS-authenticated transaction, the same dispute is decided in the bank's favor — the bank authenticated the transaction and the chargeback liability shifts to the issuing bank. The merchant dispute rate on authenticated transactions versus unauthenticated transactions from the same customer population is typically 3–5x higher on unauthenticated transactions, because the fraudulent actor knows that the merchant bears the loss. The SCA configuration — which API surface, which client-side library version, whether authentication is automatic or manual — determines which side of this liability line your European revenue sits on.

Dispute rate and network program thresholds. Visa's Dispute Monitoring Program (VDMP) enrolls merchants whose dispute rate exceeds 0.9% in a calendar month (with at least 100 disputes in the month). Mastercard's Excessive Chargeback Program (ECP) has a similar enrollment threshold at 1.5% with 100 or more chargebacks. Once enrolled, the card networks impose monthly fines that increase with each month the merchant remains above threshold: Visa VDMP fines escalate from $50 per dispute in month one to $25,000 per month for merchants who remain in the program beyond month four. The PSP (Stripe, Braintree, Adyen) passes these fines through to the merchant. Merchants who are terminated by a PSP for sustained high dispute rates may be placed on the Mastercard MATCH (Member Alert to Control High-Risk) list — which blocks the merchant from opening a new account with any Mastercard-licensed acquirer for up to five years. The dispute rate is not just a cost metric; it is an existential risk for card payment acceptance.

The PSP choice determines what dispute management tooling is available. Stripe Radar provides machine learning fraud scoring, custom rules, and a dispute evidence submission API that enables programmatic evidence upload when fighting disputes. Stripe's dispute dashboard shows dispute rates segmented by card type, geography, and product. Braintree provides dispute management but with a less developer-friendly API. Adyen's dispute management is sophisticated but requires integration with Adyen's Dispute API separately from the payment integration. The ability to fight disputes programmatically — submitting evidence via API rather than manually — and to monitor dispute rates by segment before they approach network thresholds is a structural property of the PSP tooling chosen at integration time.

Cross-border acquiring fees and settlement model. The cross-border fee structure is set at PSP selection and account configuration time. Stripe's standard pricing includes a 1.5% cross-border fee for cards issued outside the merchant's domestic settlement country (US merchant settling in USD: 1.5% on all non-US-issued cards; EU merchant settling in EUR: 1.5% on all non-EU-issued cards). This fee is in addition to the standard 2.9% + $0.30, bringing the effective rate on international transactions to 4.4% + $0.30. Adyen eliminates this through local acquiring: Adyen holds acquiring licenses in 40+ countries, processing a UK card through Adyen's UK acquiring license removes the cross-border designation and reduces the fee to approximately 1.8% all-in on interchange-plus pricing — but Adyen's pricing model requires monthly volume above approximately $500k before the fee economics favor the switch. Braintree, owned by PayPal, includes local acquiring in US, EU, UK, Australia, and Canada, with better cross-border fee economics than Stripe for merchants with significant revenue from those regions. Paddle and Lemon Squeezy as Merchant of Record process transactions in the customer's local currency through their local acquiring relationships, eliminating cross-border fees entirely from the merchant's perspective — at the cost of the MoR fee premium and the loss of direct payment relationship with the customer.

Tax compliance model and VAT/GST liability. A SaaS product selling digital goods internationally is, in most jurisdictions, required to collect and remit local sales tax — VAT in the EU and UK, GST in Australia and New Zealand, sales tax in US states with economic nexus provisions, and similar taxes in 40+ other countries. The obligation exists regardless of where the SaaS company is incorporated. Managing this independently requires registering with tax authorities in each applicable jurisdiction (EU VAT: registration required once cross-country sales in any EU member state, or use EU One Stop Shop (OSS) registration), collecting evidence of customer location (IP address + billing address + bank country — two-factor evidence requirement under EU VAT rules), remitting quarterly VAT returns to each registered jurisdiction, and managing the audit risk of incorrect filings. Tax compliance software (Avalara, TaxJar) reduces this overhead but requires integration, ongoing management, and fees. A Merchant of Record PSP (Paddle, Lemon Squeezy, FastSpring) handles all tax obligations because they are the legal seller: Paddle is the entity registered for VAT in the EU, the one filing quarterly returns and remitting to tax authorities. The merchant receives revenue net of tax without any direct tax obligation in the customer's jurisdiction. The PSP fee premium (Paddle 5% vs Stripe 2.9%) is the price of outsourcing an entire compliance function. This is the build-versus-buy decision applied to tax infrastructure, and it is made implicitly at payment processor selection time rather than explicitly as a separate tax compliance decision.

Payment processor options and their structural properties

Stripe is the correct default for most startups. The documentation is the best in the category, the integration time to first payment is measured in hours, and the Payment Intents API with Stripe.js handles 3DS/SCA automatically with correct liability shift for European transactions. Stripe Radar, enabled by default, reduces fraud rates through machine learning without requiring configuration. The Dashboard provides dispute rate tracking, payout scheduling, and revenue analytics that cover nearly all operational billing needs at early stage. The tradeoffs that matter at scale: the 1.5% cross-border fee compounds significantly as international revenue grows; Stripe is the merchant of record only in the sense that they process the transaction, not in the tax compliance sense — VAT/GST obligations remain with the merchant; Stripe Connect is the marketplace payout product, with solid documentation but requiring careful connected account verification and account structure design before the first marketplace transaction (see the authentication strategy implications for OAuth-based connected account flows). The Charges API still exists and is still working — teams building on old tutorials may use it without knowing they're giving up SCA protection.

Braintree is owned by PayPal and offers local acquiring in the US, EU, UK, Australia, and Canada — which reduces cross-border fees for merchants with significant revenue from those regions. Braintree's pricing is typically 2.59% + $0.49 for card transactions, slightly lower than Stripe's 2.9% + $0.30 on low-volume accounts, with volume discounts available. The developer experience is historically weaker than Stripe's but has improved. The important tradeoff: Braintree accepts PayPal as a payment method, which increases conversion for PayPal-preferring customers but also introduces PayPal's dispute resolution process, which has different rules from card network disputes. PayPal disputes go through PayPal's internal resolution process before escalating to the card network, and the outcomes can be less predictable than card network chargebacks. Braintree's fraud tools (Kount) are external to the core product and require separate evaluation. For products where PayPal acceptance is valuable and EU/UK local acquiring fee savings matter, Braintree is a legitimate alternative to Stripe.

Adyen is the correct choice for high-volume merchants where interchange-plus pricing and local acquiring economics justify the integration complexity. Adyen charges interchange (the fee set by Visa/Mastercard that the card-issuing bank receives) plus a small markup rather than a flat percentage — at sufficient volume, this is dramatically cheaper than Stripe's flat 2.9%. Adyen holds local acquiring licenses in 40+ countries, eliminating cross-border fees on transactions from those countries. Adyen's 3DS handling and SCA optimizations (including exemption management — requesting SCA exemptions for low-risk transactions to reduce authentication friction while staying compliant) are the most sophisticated in the market. The barriers: Adyen requires minimum monthly volumes before they will negotiate — approximately $1 million per month for standard contracts, though some programs exist for earlier-stage companies. The integration is more complex than Stripe: Adyen's API is designed for enterprise payment flows rather than startup-speed quickstarts, and the implementation time is typically measured in months rather than weeks. Adyen is not the right choice at MVP or even early growth stage; it is the right choice when the company's revenue model and international payment volumes make the fee economics material enough to justify the integration investment.

Paddle operates as Merchant of Record for digital products and software subscriptions. Paddle is the legal seller of record: they invoice your customers, collect payment, handle VAT/GST registration and remittance in 30+ countries, and manage payment method compliance. The merchant receives revenue net of Paddle's fee (5% + $0.50 per transaction) and net of applicable taxes. Cross-border fees are eliminated from the merchant's perspective because Paddle processes locally. VAT compliance is eliminated from the merchant's perspective because Paddle is the taxpayer. The structural constraints of Paddle: the customer sees "Paddle.net" or "Paddle Internet Limited" on their bank statement rather than your brand (Paddle offers a custom descriptor for an additional fee); refund and dispute resolution goes through Paddle's process, not directly through your Stripe dashboard; Paddle's product pricing page and checkout design are customizable but within Paddle's hosted checkout template (less design flexibility than Stripe's embedded Payment Element or Checkout); and the MoR model means the revenue recognition accounting is different — the amount Paddle remits to you is net of taxes, so your gross revenue in accounting terms is Paddle's net payment to you, not the gross price the customer paid. For founder-led SaaS companies with global customer bases who want to defer the tax compliance decision indefinitely, Paddle is a legitimate primary PSP choice, not just a fallback.

Lemon Squeezy operates similarly to Paddle as a Merchant of Record, with a more developer-centric positioning and a flat 5% + $0.50 pricing structure on the standard plan. Lemon Squeezy was acquired by Stripe in 2024 but continues to operate as a separate product. The MoR advantages (tax compliance, local payment) are the same as Paddle; the tradeoff versus Paddle is that Lemon Squeezy's enterprise features and international payment method breadth are narrower than Paddle's more mature product. For developer-tools products selling to a technical audience where "simple, global, no tax headache" is the billing requirement, Lemon Squeezy is a viable option. For products that need sophisticated subscription management with trials, upgrades, downgrades, and metered billing — Stripe Billing's subscription model is more capable than either Paddle's or Lemon Squeezy's subscription management.

AI chat session types and what each one misses

The payment processor setup follows a predictable session pattern. The WhyChose extractor surfaces these sessions from chat export files, and the pattern of what is covered versus what is missed is consistent across the decision records we've seen.

The initial payment setup session covers: connecting the Stripe SDK, creating a Product and Price in the Stripe dashboard, building a checkout form with Stripe.js or the Payment Element, configuring the success and cancel URL routes, handling the webhook for payment_intent.succeeded or checkout.session.completed, and verifying that a test charge in the Stripe test environment succeeds. The session is successful when the test payment goes through. What the session does not cover: whether the API version pinned in the Stripe dashboard is the current version (Stripe pins API versions per account, and older accounts may be on a version that predates certain SCA features); whether the integration uses the Charges API or Payment Intents API (both work in the test environment with identical test responses); whether 3DS challenges are triggered correctly in the test environment for European test card numbers; what the webhook retry and idempotency model is for payment processing failures; and whether the Stripe account is configured for the merchant's settlement currency and domestic region.

The subscription billing session covers: creating Stripe Billing subscription objects, configuring trial periods, handling the trial-to-paid conversion webhook, building a customer portal for subscription management, and testing upgrade and downgrade flows. What it misses: the proration model for mid-cycle upgrades (Stripe's default proration immediately charges or credits the prorated difference — which surprises customers if not surfaced in the UI); the subscription invoice payment retry behavior (Stripe Smart Retries vs fixed schedules — a choice that determines how many failed payment emails a subscriber receives before subscription cancellation); the metered billing model for usage-based pricing (requires understanding Stripe's usage records API, not just the Subscription object); and the connected account fee split model if the product ever intends to add marketplace features.

The international expansion session covers: enabling additional currencies in the Stripe account, building currency selection into the checkout UI, and verifying that a test charge in EUR or GBP succeeds. What it misses: the cross-border fee that applies to the payment (Stripe adds 1.5% for non-domestic cards regardless of which currency the charge is presented in — presenting in EUR doesn't eliminate the cross-border fee if the card is issued outside the EU settlement region); the VAT/GST registration obligation in the new market being entered (international expansion into Germany or France creates a VAT obligation for digital goods even at first sale — there is no de minimis threshold under EU VAT rules for non-EU businesses); and whether the SCA configuration that was set up in the initial payment session correctly handles 3DS for the new market's card issuer requirements.

The pattern across all three sessions is the same one documented in the new CTO onboarding problem: the setup session is oriented toward getting the first working result, and the questions that determine the structural properties of the integration — liability allocation, dispute rate exposure, fee model, compliance scope — are questions that only become visible after the integration is live. By the time they're visible, the PSP and integration approach are established, and changing them requires engineering time measured in weeks, not hours. The decision made in the setup session is the decision the business operates under until an incident reveals it.

Five ADR sections for payment processor selection

A payment processor ADR that prevents the incidents described in this post covers five sections that teams typically skip.

First, the PSP selection with alternatives and rejection reasons. The ADR records which PSP was chosen and why, alongside the alternatives explicitly evaluated. For a startup in 2024 choosing Stripe: "Stripe chosen over Paddle because the product is US-primary at launch and the VAT compliance overhead is not yet material; Paddle will be re-evaluated when EU revenue exceeds 25% of MRR or when tax registration obligations in more than three jurisdictions are triggered. Adyen evaluated and rejected: minimum volume requirements not met, 6-month integration timeline not acceptable at current stage." Recording the rejection reasons prevents the re-evaluation session in year two from starting at zero. It also makes the re-evaluation criteria explicit — not "when we feel like switching" but "when EU revenue exceeds 25% of MRR." This is the same logic as the database vendor decision record's scaling trigger: a specific measurable threshold rather than a feeling.

Second, the API surface and SCA configuration. The ADR explicitly states which Stripe API is used and what the SCA handling model is. "Payment Intents API with Stripe.js Payment Element; 3DS challenges triggered automatically by Stripe.js for cards requiring authentication; SCA liability shift applies to completed 3DS challenges on EU cards." Or, if using the Charges API: "Charges API (legacy integration from 2022 quickstart); 3DS challenges not triggered; SCA liability shift does not apply to EU card disputes; migration to Payment Intents API required before EU customer acquisition target of [date]." Documenting the existing gap directly is the first step toward closing it. The Charges API migration task does not get prioritized if no one knows the Charges API is in use. The ADR makes it legible. See also the API versioning strategy framing: the Stripe API version pinned in the dashboard is an API version decision in the same sense as the application's own API versioning.

Third, the dispute handling procedure. The ADR documents the current dispute rate by card geography (available in Stripe Radar dashboard; exportable via Stripe API), the VDMP/ECP enrollment thresholds that apply to the business, whether Stripe Radar machine learning is enabled and whether custom block rules are in place, and the dispute response procedure — who is responsible for responding to disputes, how evidence is submitted (manually via dashboard or programmatically via API), and what the maximum evidence response window is (typically 7 days for Stripe, varying by card network). The dispute rate is a metric that should be checked monthly alongside revenue, not only when it causes an incident. The observability strategy framing applies here: a metric that isn't tracked before it breaches a threshold is a metric that will be discovered after the threshold is breached.

Fourth, the cross-border fee model with projected revenue impact. The ADR documents the effective fee rate for domestic versus international transactions including the cross-border component, the current revenue split by card-issuing geography (available in Stripe's payout detail reports), the projected split at 12 and 24 months, and the fee delta between the current PSP and alternatives at those revenue projections. "At current $40k MRR with 15% EU revenue ($6k/month): cross-border fee = 1.5% × $6k = $90/month. At projected $150k MRR with 35% EU revenue ($52.5k/month): cross-border fee = 1.5% × $52.5k = $788/month ($9.4k/year). Re-evaluate Adyen at $500k MRR or at $150k/month EU volume specifically (approximately the lower bound of Adyen interchange-plus economics)." This calculation takes 20 minutes to run from Stripe's export. It is not run during the initial setup session, because EU revenue is zero and the calculation produces $0. By the time the calculation is material, the PSP is established and the switching cost has accumulated. The startup decision log captures these first-year unit economics choices; the cross-border fee model is one of the decisions that compounds invisibly until the revenue model is run at scale.

Fifth, the tax compliance model and trigger for reassessment. The ADR documents whether the business manages VAT/GST independently or through a MoR, which jurisdictions currently require registration and at what revenue threshold, and the trigger for either switching to a MoR or engaging a tax compliance software provider. "Currently self-managing VAT: registered in the UK (VAT Registration Number: [n/a at launch]), not yet registered in EU (obligation triggers at first EU sale for digital goods — no de minimis threshold). Tax compliance software not yet in use. Trigger for engaging Avalara or switching to Paddle MoR: annual EU digital services revenue exceeds £10k GBP (UK MicroBusiness VAT threshold) or annual EU VAT liability across any member state estimated above €10k." The tax obligation for digital goods in the EU is not widely understood among non-EU founders, and it applies from the first sale to an EU customer — not after some volume threshold. Documenting the obligation at PSP selection time, even when it's $0, prevents the three-year retroactive VAT liability that some non-EU SaaS founders discover only when an EU tax audit or an accountant's annual review surfaces the gap. The data retention decision has the same structure: compliance obligations that apply from day one but are only discovered under audit pressure.

None of these five sections are visible from the codebase. The Stripe SDK version, the webhook endpoint configuration, and the Stripe account settings together do not reveal whether the Charges API or Payment Intents API is in use, what the effective cross-border fee rate is on the current revenue mix, whether the business is VAT-registered in the jurisdictions where it has customers, or whether dispute rates are approaching network monitoring thresholds. These are the decisions made in the setup and expansion sessions — the sessions where the first test charge succeeded, where adding EUR pricing worked, where the subscription billing flow was confirmed — and they live in chat history until an incident makes them visible, or until the WhyChose extractor surfaces them from the export and structures them into the record the ADR needs. The ADR format guidance applies here in the same way it applies to any architectural decision: the Consequences section is where the cross-border fee projection, the SCA liability allocation, and the VAT compliance trigger all belong — the place where the real cost of the decision is made explicit before the cost is paid.

FAQs