Accepting overseas payments · PayPal and Stripe

A domestic PG may accept foreign-issued cards or overseas wallets through the products and methods covered by its contract. First check supported countries and card brands, authentication, payment currency, and settlement currency. Using a domestic provider does not by itself mean that all payments must be in won. If approval is low, separate issuer declines, authentication failures, merchant configuration, and missing payment methods. Collect failure codes and authentication results, and ask the provider about reasons the records cannot establish. Assess an additional overseas provider using payment attempts from abroad, approval rates, and checkout exits by country. A gap against domestic cards does not establish a single cause. Compare local method support and customer inquiries and check what the existing contract or configuration can address. For a proposed provider, compare expected improvement with development, operations, and reconciliation costs.

The first decision is what you show in which currency and what you actually charge in. Display currency is the price on the product page; charge currency is what the authorization runs in. Keep them the same and the customer is billed exactly what they saw, but every exchange rate move forces a repricing. Keep them different and prices stay stable while customers see a different number on their statement and write in. There is also the option of converting to the customer's currency at checkout, where who sets the rate and the margin on top of it varies by service — decide what number appears on screen along with it. Subscriptions make the decision heavier. Charging the same amount every month means fixing the currency, and fixing the currency means the felt price drifts by country as rates move. Per-country price lists protect revenue at the cost of more plans and more billing rules. Refunds bring the same problem back: when the rate on the refund date differs from the purchase date the customer receives something other than what they paid, and unless the policy says who absorbs that difference, every case is decided ad hoc. Writing display currency, charge currency, and refund reference currency into one document is what lets support give the same answer twice.

An approval is not money in the bank. An overseas provider holds a balance in your account with them and pushes it to your bank on a schedule. Four things to confirm: which currency you receive, who performs the conversion if you take won — the provider or your bank, which bank and account type you need if you take foreign currency, and when the first payout leaves. New accounts often carry a hold on funds for a period, and the share held rises again when cancellations and disputes grow. Where the conversion happens decides what actually arrives. Letting the provider send won is convenient but the conversion follows their policy; receiving foreign currency lets you choose bank terms at the cost of a foreign currency account and a receiving procedure. Finance has one more gap to manage — revenue recognition and the date cash lands drift apart — so the provider balance and the bank deposit need to be reconciled as two separate lines. Payout statements are also structured differently from domestic ones. Per-transaction fees, conversion amounts, funds clawed back by chargebacks and the cost of handling them, and refunded amounts all arrive in one file, so decide up front which items reduce revenue and which are booked as cost. Without that rule, month-end repeats the same judgement.

Cross-border tax requirements are not determined by the customer's country alone. The seller, product, destination market, and whether the transaction is business-to-business or consumer-facing change what must be checked. After defining the markets and transaction structure, confirm registration, filing, tax treatment, and evidence requirements with the tax team or adviser. Integration design then establishes the required inputs and where to retain them. Collect customer country, billing address, business status, and registration identifiers only as needed for the transaction. Align tax-inclusive or tax-exclusive prices and invoice and receipt fields with the confirmed requirements. Define how subscription changes and refunds update tax amounts and documents, and record the review date and owner. If the provider offers tax calculation, confirm its coverage and who owns configuration. Before launch, check that the order, payment, tax record, and receipt refer to the same transaction.

Attaching an overseas provider takes longer in account review than in API work. PayPal and Stripe vary their terms and available features by the country the entity is registered in, and onboarding asks for corporate documents, identity verification for representatives, a description of the business, and expected volume. The website is reviewed as well: what you sell, whether prices and shipping terms are stated, whether a refund policy and contact details are published, and whether the terms of service match the actual service. Items no domestic review asked for surface here, so page edits belong in the integration schedule. Both providers publish a list of businesses they cannot support, so check it against your category before signing. On the feature side several things differ from domestic practice — separating authorization from capture, region-specific payment methods, and taking subscription billing or tax calculation as provider features. A service running a domestic PG alongside an overseas provider should not scatter those differences through product code; keep one transaction contract and absorb them in adapters. Which transactions go to which provider is written as a rule, keyed on issuing country, the currency the customer chose, or product type, with failover when one side slows. Generate order numbers and transaction identifiers under the same scheme on both sides, or reconciliation and support lookups will not finish on one screen.

The heaviest new operational load in cross-border payments is the chargeback. When a customer raises the issue with their issuer rather than with you, the funds are pulled first and you argue afterwards by filing evidence within a set window. That is a different procedure from a domestic refund, which ends with your own decision. Evidence preparation decides the outcome: order timestamp and access records, tracking number and delivery confirmation, account activity logs for digital goods, and the moment terms were accepted along with the screen that showed the refund policy. Gathering this after the fact misses the deadline, so the real answer is to accumulate it automatically per transaction. A rising chargeback rate makes the provider raise the held share or revisit your account terms, so manage the rate itself as a metric. Work the other side too. Put a merchant descriptor on the statement that customers recognize, notify subscribers before charging, and place the refund request path somewhere easier to find than the issuer's, and more cases end before they become disputes. Chargebacks from stolen card data behave differently: no amount of evidence reliably keeps the funds, so placing a risk decision ahead of authorization costs less than fighting afterwards. Where that decision sits and which transactions get step-up authentication depend on payment method and product type, so settle both during integration design.