.png)
Every payment gateway has to answer one question at the moment a buyer pays: where does the card data get entered, and who is responsible for it. There are two answers. They look the same to a buyer. They are very different for your business.
Get this choice right and you match the trade-offs to what you actually need. Get it wrong and you either give up control you wanted or take on compliance weight you did not. Here is how the two models compare, and how to pick.
With a hosted checkout, the buyer goes to a payment page the gateway runs, enters their card, and comes back once the payment is done. The card data never touches your servers.
That one fact drives everything. Because the sensitive data is captured on the provider's side, your PCI compliance scope shrinks dramatically. The provider carries the security hardening, the tokenization, and much of the fraud tooling. What you give up is control: you style the page within the provider's limits, but the flow and the redirect belong to the gateway.
For most businesses that is a good trade. The compliance and security savings are large, and the loss of control is small, especially now that hosted pages can be themed to match your brand closely.
With a direct API integration, the buyer stays on your pages, card details are captured there, and passed to the gateway through its API. No redirect. The experience is entirely yours.
The upside is total control: the checkout looks and behaves exactly as you designed, with nothing imposed by the provider. The cost is real. Capturing card data on your own pages pulls you into a much larger PCI scope, and the engineering and security work rises with it. This model suits businesses with the resources to carry that weight and a strong reason to own the whole experience, usually large merchants and platforms building their own checkout.
The choice is not really binary anymore. Most gateways offer a drop-in or embedded-fields model that sits between the two. The payment fields are hosted by the provider but rendered inline on your page, usually in an iframe. The buyer never leaves your site, so it feels native. But because the sensitive fields are technically served by the provider, your compliance scope stays close to the hosted model.
For a lot of businesses, this is the sweet spot: a checkout that looks like yours, without the full PCI weight of a direct API build. You get most of the control of API-direct and most of the compliance relief of hosted, at once.
A common mistake is to reach for the full API build for control the business never actually uses. Teams picture a bespoke checkout, then ship something that looks almost identical to what an embedded model would have given them, having taken on the full PCI scope for the difference. Start from what you genuinely need to control, not from what is possible. For most businesses, the honest answer points to hosted or embedded.
The decision is not only about launch effort. It is about who carries the maintenance.
Card standards change. Authentication rules shift by market. New payment methods appear constantly. With a hosted or embedded model, the provider absorbs most of that ongoing work, keeping the page compliant, rolling out new authentication, adding local methods. With a direct API build, much of that upkeep lands on your engineering team, and it does not stop. For a business selling across many markets, that open-ended burden often outweighs the one-time appeal of a fully custom checkout. It just does not show up on launch day.
Three questions settle it. How much control do you genuinely need, not just want? How much PCI and security weight can you carry? And how much engineering time do you have to build and maintain a checkout?
Want to launch fast, keep compliance light, and accept a themed page? Hosted checkout. Need the checkout on your own pages but not the full custom build? Embedded or drop-in. Have a real reason to own the entire experience and the resources for full PCI scope? Direct API.
For cross-border businesses there is one more factor: coverage. Whichever model you pick, the gateway underneath has to support the local methods and currencies your buyers expect in each market, which is where a cross-border payment gateway earns its place. And whichever you pick, running 3DS authentication through it keeps fraud and chargebacks down without adding needless friction.
The right integration is the one whose trade-offs match your business, not the one with the most control on paper. For most, that is hosted or a hosted-backed embedded checkout: enough ownership of the experience, without inheriting the weight of running a card-capturing page yourself.
[1] PCI Security Standards Council. "PCI DSS and payment security standards." 2026.
Sell across borders long enough and chargebacks stop looking like fraud. Most of them are not. They are buyers disputing real purchases, because something about the payment looked wrong. And cross-border payments are very good at looking wrong.
So the question is not how to stop fraudsters. It is how to stop the avoidable disputes without adding friction that costs you good customers. Here is how.
A chargeback is a forced reversal of a card payment, initiated by the cardholder's bank rather than by the business. The buyer disputes a charge with their issuing bank, and if the bank sides with them, it pulls the funds back out of your account through the card network.
It is not the same as a refund. A refund is something you choose to give; a chargeback is imposed on you, often without warning, and it usually carries a fee on top of the reversed amount. Chargebacks exist to protect cardholders from fraud and non-delivery, and for genuine cases they do exactly that. The problem, especially across borders, is how many of them are disputes over payments the buyer actually made.
Same card rails, more ways to go wrong. Four things stack up on an international sale.
1. The buyer does not recognize the charge. An unfamiliar merchant name, a foreign currency, a conversion rate they did not expect, and the buyer disputes their own purchase. This is the biggest avoidable cause, and it has nothing to do with fraud.
2. Delivery takes longer. A bigger gap between paying and receiving gives the buyer more room to assume the order is not coming.
3. Stolen cards get tested across borders. Issuers have fewer local signals to judge a foreign payment, so fraud concentrates there.
4. Real buyers dispute real purchases. First-party, or friendly, fraud is harder to challenge when buyer and business sit in different countries.
A chargeback is not one event. It moves through a set sequence, and knowing where you can act matters as much as knowing why it happened.
The buyer contacts their bank and disputes the charge. The bank assigns a reason code and pulls the funds back from you, through the card network and your acquirer. You get notified, and you can fight it with representment: sending evidence that the payment was valid, like proof of delivery or the buyer's own authorization. If the evidence holds, you get the money back. If it does not, the case can go to arbitration, where the card network decides and charges the loser a fee.
Two points carry all the weight. Stop the dispute before it is filed, and win representment with clean evidence when it is. Everything after that is slower, costlier, and less certain.
There is no single fix. It is a stack of small, cheap controls, each closing off one of the drivers above.
1. Authenticate with 3DS. 3-D Secure verifies the buyer with their bank at checkout, and on authenticated payments it shifts liability for fraud disputes to the issuer. Modern 3DS lets most low-risk payments through with no challenge, so the friction is far lower than it used to be. This is covered in depth in the guide to how a 3DS-enabled payment gateway reduces fraud.
2. Check the card and address. Card verification and address checks catch a share of stolen-card attempts before the payment completes, which is exactly where cross-border fraud sits.
3. Fix your billing descriptor. A clear, recognizable name on the statement, ideally with a support contact, is the cheapest chargeback prevention there is. Many non-recognition disputes simply never happen.
4. Show the currency plainly. Display the amount and currency clearly at checkout, and keep conversion transparent. That removes the statement surprise that triggers non-recognition.
5. Screen for cross-border fraud. Tools tuned for international traffic, mismatched geolocation, odd velocity, high-risk corridors, stop a share of disputes at the point of payment.
6. Keep clean evidence. Retain proof of delivery, authentication records, and the buyer's authorization, organized so you can answer a dispute fast and inside the deadline.
Stack these and the dispute rate drops without checkout turning into an obstacle course. The goal is not zero friction or zero disputes. It is stopping the avoidable ones while good customers keep converting.
When a dispute is worth contesting, the case is won or lost on evidence. So it pays to know what a strong representment looks like before you need one.
The strongest evidence ties the payment to the buyer and the delivery together. Proof of delivery with tracking, a signature, or a download log. Authentication records showing the payment passed 3DS. The buyer's own authorization, the checkout record, IP, device, and the details they entered. And any prior history with the same customer that shows a normal relationship, not fraud.
Two things sink a good case. Missing the network's response deadline, and evidence that is scattered across systems and cannot be pulled together in time. Both are avoidable. The businesses that win representment are simply the ones that kept the record clean and answered fast, which is far easier when the gateway collects the evidence for you as each payment happens.
Most of these controls live in the gateway. A capable cross-border payment gateway gives you built-in 3DS, card and address checks, configurable descriptors, and fraud screening built for international traffic, with dispute evidence collected automatically so representment is fast instead of a scramble.
Cross-border chargebacks are a cost of selling internationally. But most of that cost is optional. The businesses that keep their rate low did not build the strictest checkout. They made their charges recognizable, authenticated the risky payments, and kept the evidence to win the disputes worth fighting.
[1] EMVCo. "EMV 3-D Secure." 2026.
[2] PCI Security Standards Council. "PCI Security Standards Overview." 2026.
Fraud hits harder on cross-border payments. The buyer's bank has fewer local signals to judge a foreign payment, and stolen cards get tested across borders on purpose. 3-D Secure is the card networks' answer: verify the buyer with their own bank at the moment they pay, so you are not left guessing whether the person holding the card actually owns it.
Here is what 3DS does, why the modern version does not wreck checkout, and why running it is one of the best fraud controls a cross-border business has.
3DS adds an authentication layer between three parties: you, the card network, and the buyer's bank. When a buyer pays, the transaction goes to their bank to verify before it is authorized. The bank confirms the buyer's identity and returns a result that tells you whether the payment is authenticated.
The point is simple. It moves the question of who is really paying from you, who cannot answer it well, to the bank, which can. The bank knows the customer, holds their authentication, and sees their account behavior. 3DS is the channel that lets the bank use all of that at the exact moment a cross-border payment happens.
The most valuable thing 3DS does is move liability. On a payment authenticated through 3DS, responsibility for a fraud chargeback generally shifts from you to the card issuer. If an authenticated payment later turns out fraudulent, you are typically protected from that dispute.
For a cross-border business, that is a big deal. Fraud disputes are where a large share of cross-border chargeback losses come from, and they are the hardest to win at representment. Shifting that liability to the issuer removes a whole category of loss you would otherwise eat.
The 3DS many businesses remember, a clunky password page that killed sales, is not the version in use today. Modern 3-D Secure exchanges far more data between you, the gateway, and the bank at the moment of payment, so the bank can judge risk before deciding whether to challenge the buyer at all.
The result: most low-risk payments get authenticated silently, with no step the buyer even sees. Only genuinely risky ones trigger a challenge, a one-time code, or a biometric approval in the banking app. That frictionless path is what makes 3DS practical to run on all traffic, not just the riskiest. Wide protection, narrow friction. For a cross-border business, that combination is exactly what the old version lacked.
The frictionless path also leaves room for deliberate exemptions. Low-value payments, trusted repeat beneficiaries, and payments the bank scores as low risk can pass without a challenge under the rules, so the friction lands only where it earns its keep.
In some regions, authentication is not optional. Under strong customer authentication rules in the European Economic Area, many online card payments must be authenticated, and 3DS is how you meet the requirement. So a gateway that runs 3DS well does two jobs at once: it cuts fraud, and it keeps you compliant with regional authentication rules.
3DS is powerful. It is not a complete fraud strategy on its own. It authenticates the buyer; it does not, by itself, catch every kind of abuse.
The businesses with the lowest fraud run 3DS alongside the rest of the stack: card and address checks to catch stolen-card attempts, fraud screening tuned for cross-border traffic to flag odd velocity or geolocation, and clean records for the disputes that still slip through. 3DS settles the authentication question and shifts the liability that comes with it. The rest of the stack handles what authentication alone does not. Treated as one strong layer rather than the whole thing, 3DS is where the single biggest drop in cross-border fraud losses comes from.
Every benefit of 3DS is bigger on cross-border payments. The fraud it blocks concentrates there. The chargebacks whose liability it shifts are the hardest to contest across jurisdictions. And the authentication rules it satisfies vary market by market, so a gateway that handles 3DS intelligently across regions clears a compliance headache you would otherwise manage yourself.
There is a practical payoff beyond fraud, too. Authenticated payments tend to see higher issuer approval rates, because the bank has more confidence the payment is genuine. So 3DS does not only cut disputes; on cross-border traffic it can also recover good payments that a nervous issuer would otherwise decline.
A 3DS-enabled cross-border payment gateway applies the right level of authentication per payment and per market: frictionless where risk is low, a challenge where it is high, full authentication where a region demands it. Paired with the other controls in our guide to cross-border chargebacks, it is the most effective way to cut fraud without cutting conversion.
3DS used to force a choice between security and sales. Not anymore. It protects the whole book while only stopping the buyers who warrant a second look, which is why, for anyone selling across borders, running it through the gateway is close to free protection, and one of the few fraud controls that pays for itself from the first authenticated payment.
[1] EMVCo. "EMV 3-D Secure." 2026.
[2] European Banking Authority. "Strong customer authentication under PSD2." 2026.
The US to India corridor is really two corridors, and conflating them is the most common planning error.
Inbound to India means a US business collecting from Indian customers, whether consumers buying from a D2C brand or businesses buying software and services. From India's regulatory perspective the Indian buyer is importing, and the collection is governed by the cross-border payment aggregation framework.
Outbound means a US business paying Indian entities: development firms, outsourcing providers, agencies, contractors, distributors and suppliers. India is a major services exporter, so for a large share of US companies this direction carries real volume.
Different regulation, different rails, different providers, different failure modes.
Since the RBI's October 2023 circular on the regulation of Payment Aggregators for cross-border transactions, all entities facilitating cross-border payments for Indian import or export are regulated directly by the Reserve Bank of India as PA-CBs [1]. Before that, the activity sat with Authorised Dealer banks under the older and narrower OPGSP arrangement.
The framework opened the activity to non-bank entities, which is why the provider landscape looks the way it does. It also brought those entities under direct RBI governance with compliance obligations equivalent to and in places heavier than a domestic payment aggregator [2].
For a US business, the translation is short: collecting from Indian customers requires an RBI-authorised PA-CB partner or a bank [3].
Three authorisation categories exist [3]:
A US merchant collecting from Indian buyers needs a provider with import-capable authorisation.
The entry bar is deliberately high. Non-bank PA-CBs require minimum net worth of INR 15 crore at application, rising to INR 25 crore by 31 March 2026, with FIU-India registration as a prerequisite [2][4]. Import-only PA-CBs must maintain an Import Collection Account with an AD Category-1 scheduled commercial bank, and funds pass through a defined account structure before reaching the foreign merchant [2].
By early 2026 the RBI had authorised roughly 19 to 25 entities, with approvals arriving in waves since mid-2024 [3][5]. Named holders include Cashfree Payments, Amazon Pay India, Adyen India, BillDesk, Razorpay, PayU and Worldline [3][5].
Two due-diligence points. The RBI publishes a regularly updated list of domestic online payment aggregators but, as of early 2026, does not maintain a single always-current public page dedicated to PA-CB authorisations [3]. And in-principle approval is not a final licence [5]. The two get reported interchangeably and they are not the same thing.
Once licensing is settled, the checkout question is comparatively simple because the market is concentrated.
UPI carries around 85% of India's digital payments and processed 23.2 billion transactions in May 2026 alone [6]. For consumer and D2C checkout it is the default, and everything else is a supplement. Our blog on how UPI works covers the mechanics and app landscape.
The failure mode worth naming: a card-first checkout imported from US or European markets underperforms in India for structural reasons unrelated to your product. Card penetration is low relative to UPI adoption and the consumer reflex is to select UPI.
Cards matter for higher-value purchases, corporate card programmes and self-serve software licences where a business user transacts without procurement involvement. RuPay is the domestic network alongside Visa and Mastercard, and RuPay credit cards can now link to UPI.
Net banking persists for higher-value e-commerce and among buyers who prefer a bank-authorised flow.
For invoiced B2B, bank transfer is the normal instrument, for the same reason it is in most markets: values exceed card comfort levels and the buyer's finance function controls the payment.
Three features of this corridor change what your checkout can do, and all three surprise teams that have only built for US or European markets.
The tokenisation constraint catches product teams hardest. RBI rules restricting merchant storage of card credentials apply to PA-CBs as they do to domestic aggregators [7]. A returning-customer flow assuming a stored card behaves differently in India, and the design work belongs before launch rather than after.
The value cap tends to surface after launch rather than before. INR 25,00,000 is roughly where enterprise contracts and larger service engagements sit, so a corridor validated on mid-market values can fail on the deals that matter most.
For many US businesses this is the larger flow. India exports software development, IT services and outsourced business functions at enormous scale.
Outbound payments run over correspondent banking, or over domestic INR rails through a provider holding the relevant banking relationships. The operational questions are corridor coverage, settlement timing, and the quality of payment data arriving with the funds.
Within India the receiving rails are the bank ones. NEFT carries routine business transfers in batches, RTGS handles high-value settlement individually, and IMPS provides continuous availability at lower values. UPI, despite its dominance of digital payments by volume, is structurally a consumer retail rail with an average ticket near Rs 1,348 [6]. It is not where business value moves.
One dependency becomes non-optional shortly. From 14 November 2026, SWIFT will reject cross-border payment messages carrying fully unstructured postal addresses, and the requirement flows upstream into payment initiation files. For anyone running volume payouts into India over SWIFT, beneficiary address data quality becomes an operational prerequisite. Our ISO 20022 November 2026 guide covers the scope.
Confirm your provider holds a final PA-CB licence, not in-principle approval [5].
Confirm the authorisation category matches your direction. Export-only does not enable import flows [3].
Build for UPI first if you sell to consumers. Card-first design imported from other markets underperforms here [6].
Test the value cap against your largest expected transaction, not your average. INR 25,00,000 per unit is where enterprise B2B hits the ceiling [7].
Design for tokenisation constraints from the start. Retrofitting a repeat-purchase flow costs more than building it correctly [7].
Scope inbound and outbound separately. Different regulation, different rails, frequently different providers.
For businesses paying Indian suppliers, contractors and sellers, corridor coverage and payment data quality determine whether payments arrive cleanly or generate exceptions.
The two directions of the US-India corridor need different infrastructure, and Tazapay covers both. Its payment gateway supports UPI and card acceptance for collecting from Indian buyers under the PA-CB framework, while its payout coverage moves business value to Indian counterparties through NEFT, RTGS and IMPS with the structured data that keeps SWIFT payments clean ahead of the November 2026 change.
[1] Reserve Bank of India, "Regulation of Payment Aggregator – Cross Border," circular dated October 2023, summarised at
[2] LKS. "Cross-border payments for Indian businesses: Impact of RBI's new guidelines."
[3] EximPe. "The Complete List of RBI PA-CB Licensees in India 2026." March 2026.
[4] Enterslice. "Cross-Border Payment Aggregators: 2026 RBI Regulations." June 2026.
[5] EximPe. "PA-CB License India: RBI Payment Aggregator Cross Border."
[6] CoinLaw. "UPI Statistics 2026: 23.2 Billion Monthly Transactions and 49% of Global Real-Time Volume." June 2026.
[7] PwC India. "Cross-border payment aggregators: Regulations and business use cases."
[8] Ikigai Law. "RBI Rewrites the Payment Aggregator Rulebook." September 2025.
.png)
The two approaches sit at different points on a spectrum between speed of setup and depth of control.
A payment link is a URL that points to a hosted checkout page run by the payment provider. The URL references the product, price and any configured options. The customer clicks the link, enters their details on a secure page, and pays. There is no code, no integration project, and no hosted storefront required [1].
A payment API integrates payment acceptance directly into a business's own website or application. The business controls the checkout flow, the interface, and how payment connects to its internal systems. This requires engineering work to implement, but in return it gives full control over the experience and can connect payment deeply to internal systems like accounting, reporting, and order management [2].
Between the two sits hosted checkout, a provider-hosted payment page that the customer is redirected to or that is embedded in a defined format. It is faster to integrate than a full API build while offering more structure than a bare link [3].
Payment links are advantageous wherever the setup cost of an integration is not justified, or where the payment happens outside a website checkout flow.
The clearest cases [2][4]:
Modern payment links have also gained capability. They are no longer a static URL with a price attached, and good providers support prefilling, mobile-optimised rendering and configurable post-payment behaviour [1]. The design details matter because checkout design measurably drives conversion. Baymard Institute, whose meta-analysis of 50 studies puts the average cart abandonment rate at roughly 70%, finds that resolving documented checkout usability issues can lift conversion by as much as 35% [5]. A well-designed payment link can convert at a rate close to a full embedded checkout, while a poorly designed one, with weak defaults or bad mobile rendering, can drop conversion substantially [1]. The link being simple to create does not mean the details stop mattering.
Payment APIs are the right choice where the business needs control, scale, or integration that a hosted page cannot provide.
The clearest cases [2][4]:
The trade-off is the integration effort. A full API build requires engineering time and ongoing maintenance, which is precisely why it is worth it only where the control and integration genuinely add value [3].
Many businesses use both, matched to the situation rather than standardised on one.
A business with a full API-integrated checkout on its website may still use payment links for invoicing, for sales handled over a call, or for a customer who abandoned a cart and needs a follow-up nudge [4]. The API handles the high-volume automated flow; the link handles the exceptions and the human-initiated payments.
This is why the question is better framed as which tool fits which flow, rather than which tool a business should adopt exclusively. The relevant unit is the payment scenario, not the company.
Three questions resolve most of the choice.
Do you have engineering capacity, and is the flow worth an integration? If the answer to either is no, a payment link or hosted checkout is the pragmatic route. A full API build is worth it only where control or integration genuinely adds value [3]. The build and maintenance effort is a real cost to weigh, which we cover in our breakdown of where payment gateway fees actually go.
Is the customer mid-flow on your website, or are you reaching them elsewhere? A customer already in a website checkout is served best by an integrated flow. A customer being invoiced, messaged, or met in person is served best by a link [1][4].
Do you need to split payments, adjust fees, or connect to internal systems? These are API territory. Marketplaces splitting payments between sellers, platforms adjusting fees, and businesses that need reconciliation to happen automatically all need the depth an API provides [2][4].
For businesses selling to consumers or other businesses through a website, an API-integrated checkout owns the primary flow. For invoicing, intermediated sales, and asynchronous collection, payment links do the job without an engineering project. Our payment gateway supports both, so the same provider covers the website checkout and the invoice-by-link scenario.
For the related question of hosted versus fully native checkout specifically, see our companion coverage on hosted vs native payment gateways.
[1] Dodo Payments. "What Is a Payment Link? A Founder's Guide to Linkable Checkouts in 2026." May 2026.
[2] GR4VY. "Hosted checkout vs API checkout: which payment integration is right for your business?" June 2026.
[3] Adyen, via Pakaidonk. "Payment Link, Hosted Checkout, or API: Which is Right for Your Business?" April 2026.
[4] Baymard Institute. "50 Cart Abandonment Rate Statistics." Updated September 2025.
.png)
A payment either works or it does not. That is the entire experience from the outside. What the invoice shows you is a single number, and what the customer sees is a confirmation screen. Neither reveals the four or five separate parties that took a cut on the way through.
Every card transaction passes through five distinct fee layers. The pricing model your provider uses does not change which layers exist. It only changes which of them you see itemized [1].
The layers at the top of that table are set by the card networks and move for nobody. The layer at the bottom is the one that determines whether a cross-border transaction costs roughly what a domestic one does, or several times more.
Interchange is the fee the acquiring bank pays to the cardholder's issuing bank on every card transaction. It is set by Visa and Mastercard through published rate tables, and no party in the payment chain can alter it [2]. It is typically the largest single component of a domestic transaction.
The rate varies by card type, transaction method, and geography. In the EU, consumer card interchange is capped at 0.2% for debit and 0.3% for credit under the Interchange Fee Regulation [3]. In the US, interchange is uncapped and typically runs from 1.0-2.5% depending on the card product. A UK consumer debit card carries roughly 0.2%. A US business rewards card can carry 2.5% [4].
This matters for a reason that has nothing to do with pricing conversations. Interchange is why the same product, sold at the same price, costs a merchant a different amount depending on which card the customer happened to reach for. It is the clearest demonstration that payment cost is a property of the transaction, not of the provider.
What does move interchange is the data attached to the transaction. Sending Level 2 and Level 3 data on B2B payments can qualify a transaction for a lower interchange category. 3D Secure authentication qualifies transactions as lower risk. Prompt settlement avoids downgrade surcharges [2]. These are transaction-level engineering decisions rather than commercial ones, and they are available to any merchant regardless of who processes their payments.
On domestic transactions, this layer does not exist at all. On cross-border transactions it is frequently the largest one, and it is the only layer that never appears as a line item.
When a customer pays in one currency and the merchant settles in another, a conversion happens somewhere in the chain. The difference between the mid-market reference rate and the rate applied at conversion is the FX spread. It is embedded in the exchange rate rather than charged as a fee, which is why it stays invisible on an invoice even when it is the largest cost in the transaction [4].
The size of that spread is a function of the corridor, not of anyone's generosity. Major pairs like USD/EUR and USD/GBP are deep, heavily traded, and tightly priced. Emerging market pairs are thinner, involve fewer counterparties willing to hold the currency, and price accordingly. Converting into a freely floating, deeply traded currency and converting into a managed, thinly traded one are not the same operation and do not cost the same.
The number of parties touching the money matters as much as the currency pair. A payment that crosses three correspondent banks is priced more than once on the way through. The stablecoin sandwich settlement model exists largely because collapsing that chain removes the intermediate steps that each carry a spread.
Every layer in the stack gets more expensive when the transaction crosses a border, and the layers compound.
When the customer's issuing bank sits in a different country from the acquiring bank, the card networks apply higher interchange rates and add cross-border scheme fees. The acquirer carries additional cost for the same transaction. And the FX spread, which was zero domestically, now applies [2].
A transaction that costs roughly 2% domestically can cost several times that cross-border once every layer is accounted for [4]. This is not a pricing failure or a provider being opportunistic. It is what the transaction actually costs to move through the infrastructure it has been routed through.
Which points at where the real lever sits.
The most consequential variable in cross-border payment cost is not what any individual layer is priced at. It is whether the transaction is processed as a domestic transaction or a foreign one in the first place.
Local acquiring means processing through an acquiring entity in the customer's own country. The issuing bank then sees a domestic transaction rather than a foreign one. The cross-border interchange premium does not apply, because it is no longer a cross-border transaction. The cross-border scheme fees do not apply. And because settlement happens in local currency, FX conversion moves from the transaction layer to the settlement layer, where it can be handled once in aggregate rather than repeatedly on every individual payment.
The revenue effect is larger than the cost effect, and it is the part most businesses miss. Issuing banks apply stricter fraud scoring to foreign transactions, so cross-border authorization rates run materially below domestic ones. Data across providers shows local acquiring improving cross-border approval rates by 16-20% [6]. On meaningful volume, transactions that were previously being declined and are now approved outweigh any individual fee line by a wide margin.
This is why the cost conversation and the conversion conversation are the same conversation, and why treating payment cost purely as a procurement exercise misses where most of the money actually is.
Both pricing models contain all five layers. The difference is visibility, not total.
Flat-rate pricing bundles everything into a single percentage plus a fixed per-transaction fee. It is predictable and simple to forecast, which for many businesses is worth more than granularity. The trade-off is that a low-interchange EU debit card and a high-interchange US rewards card are billed identically, so the blended rate is doing the work of smoothing the difference.
Interchange-plus pricing separates pass-through interchange from the provider's margin. Each transaction is billed at its actual interchange plus a defined margin. It is less predictable month to month, because the card mix moves, but it makes the underlying structure visible [5].
Neither model is universally better. Flat-rate suits businesses that value forecastability and have a stable card mix. Interchange-plus suits businesses whose card mix skews toward lower-interchange products, where a blended rate would be working against them. The right answer depends on the shape of the transaction base, not on which model is cheaper in the abstract.
For businesses thinking about how a gateway fits a cross-border operation more broadly, including acceptance breadth, authorization performance, and payout capability, our international payment gateway guide covers the wider evaluation.
Thailand's shift to digital payments is the most complete in Southeast Asia. Account-to-account (A2A) payments captured 44% of e-commerce transaction value and 43% of point-of-sale value in 2025, the highest A2A share of any market in the region [1]. Cards remain relevant for higher-value purchases and international transactions, but PromptPay has become the default payment method for the majority of Thai consumers.
Thailand's mobile payments market is estimated at $34.08 billion in 2026, growing from $29.73 billion in 2025 at a CAGR of 14.62% through 2031 [2]. Three digital bank licenses were granted in April 2025 (Krungthai-AIS-Gulf-OR, SCBX-KakaoBank-WeBank, and Ascend Money-Ant International), adding competitive pressure that will deepen wallet adoption further [2].
PromptPay is Thailand's national QR-based payment system, overseen by the Bank of Thailand and operated through National ITMX. It allows users to send money instantly using mobile numbers, national ID numbers, or merchant QR codes.
The numbers define its dominance: 74 million registered users and over 74 million transactions processed daily [1]. Person-to-person transfers are free, a deliberate policy by the Bank of Thailand to drive financial inclusion. Merchant acceptance is embedded into every domestic bank app, making PromptPay as ubiquitous as cash was a decade ago.
PromptPay transfers captured 41.10% of Thailand's mobile payments market share in 2025 [2]. The system's strength comes from its status as public infrastructure rather than a commercial product. Unlike private wallets that compete for users, PromptPay sits beneath every bank and wallet, creating a universal acceptance layer.
For international businesses, the practical consequence is that a checkout without PromptPay loses access to 44% of Thai e-commerce spending. Integrating PromptPay through a payment gateway with Thai coverage is the single highest-impact action for conversion in this market.
TrueMoney holds approximately 16.8% of Thailand's wallet market share and serves a fundamentally different population segment than PromptPay. With 39,000 agent outlets across Thailand, TrueMoney functions as a cash-in network that converts physical cash into digital payments for consumers who do not have bank accounts or prefer not to use online banking [2].
TrueMoney's mobile wallet CAGR is 16.2%, and it could expand the Thai mobile payments market by $13.4 billion between 2026 and 2031 as it penetrates cash-heavy provinces outside Bangkok [2]. For international businesses targeting the Thai mass market beyond urban Bangkok, TrueMoney adds reach into a consumer segment that PromptPay alone does not fully cover.
Beyond PromptPay and TrueMoney, three additional wallets hold meaningful positions.
Rabbit LINE Pay integrates with Bangkok's BTS Skytrain system and the LINE messaging app. It bundles transit payments with micro-insurance and retail offers. Its user base skews urban and commuter-centric.
ShopeePay is the payment arm of Shopee, Southeast Asia's largest e-commerce platform. For merchants already selling on Shopee Thailand, ShopeePay integration is native to the platform.
GrabPay ties into Grab's ride-hailing and food delivery ecosystem. Grab Thailand's S.M.A.R.T. roadmap (announced April 2025) deepens the integration between rides, food, parcels, and GrabPay payments [2].
None of these wallets individually approach PromptPay's transaction volume, but together they represent the convenience layer that Thai consumers use for daily spending within specific ecosystems.
Thailand is at the center of Southeast Asia's cross-border QR payment network. PromptPay is now connected to more partner systems than any other national payment rail in the region.
The live cross-border connections include Singapore's PayNow (operational since April 2021, the first bilateral IPS link in ASEAN), Malaysia's DuitNow, Indonesia's QRIS, and Vietnam's VietQR [3]. A Thai tourist in Singapore can pay using PromptPay at any PayNow-accepting merchant. A Singaporean visiting Bangkok can pay with PayNow at PromptPay merchants.
Thailand is also a founding member of Project Nexus, the BIS-led multilateral platform linking real-time payment systems across Indonesia, Malaysia, Singapore, Thailand, the Philippines, and India. Project Nexus incorporated in Singapore in March 2025 and is expected to go live in 2026 [4].
For international businesses with customers or supply chains across ASEAN, these cross-border QR connections mean that a single Thai PromptPay integration increasingly enables acceptance of inbound payments from neighbouring countries. For the broader picture of how e-wallets work across Southeast Asia, including country-by-country breakdowns, see our SEA payments guide.
Three priorities for accepting payments in Thailand.
First, integrate PromptPay. This is the single most important payment method in Thailand. Without it, your checkout is inaccessible to the majority of Thai consumers. A payment gateway with PromptPay integration through National ITMX is the standard approach for international merchants.
Second, maintain card acceptance for higher-value transactions. Cards still account for a meaningful share of Thai e-commerce, particularly for international purchases, travel bookings, and premium goods. PromptPay and cards together cover the vast majority of Thai spending.
Third, consider TrueMoney for mass-market reach. If your business targets consumers outside Bangkok or in lower-income segments, TrueMoney's agent network provides cash-in capability that extends your addressable market beyond banked populations.
For businesses also paying out to Thai beneficiaries, Thailand is well-served by local rail payouts through PromptPay, with same-day settlement at significantly lower cost than SWIFT.
[1] Digital in Asia. "How Do Digital Payments Work in Southeast Asia in 2026?" June 2026. https://digitalinasia.com/how-digital-payments-work-in-southeast-asia/
[2] Mordor Intelligence. "Thailand Mobile Payments Market Report." January 2026. https://www.mordorintelligence.com/industry-reports/thailand-mobile-payments-market
[3] Digital in Asia. "State of Digital Payments Across Asia: A 15-Market Tracker." May 2026. https://digitalinasia.com/asia-digital-payments-tracker/
[4] BIS Innovation Hub. "Project Nexus: Enabling Instant Cross-Border Payments." https://www.bis.org/about/bisih/topics/fmis/nexus.htm
