6Getting paid
How to Choose a Payment Provider for a Cross-Border Store
A customer being able to pay does not mean your business can open an account with the provider you are considering. Merchant eligibility and the customer's payment options are separate questions. Begin with the business you actually operate, then trace how an order would become a payout in your bank account.
Confirm eligibility before building the integration
Check the provider's current supported business locations, documentation requirements and restricted activities against your legal entity and products. The customer's location is not a substitute for merchant eligibility.
Use accurate business information. If the arrangement is unsupported, compare another suitable provider instead of treating a technical integration as a way around the restriction. Also identify which payment methods are available for your account and markets; a provider offering a method somewhere does not mean it is available in every setup.
For Stripe, the global availability page is a starting point, followed by the terms and restricted-business information for your account. For PayPal, consult the agreement and fee information for the business account's country. Confirm unresolved points directly with the provider before committing to an implementation.
Draw the payment and payout as separate steps
Record the currency in which the customer pays, the currency in which you receive a payout, and where conversion may occur. Then list processing charges, conversion charges and other applicable deductions. Do not assume that the amount displayed on the order is the amount that will reach your bank.
Use an illustrative order of a $40 storage bag plus $6 shipping to map the records. The order should have an identifier you can match to the payment transaction and subsequent payout records. A payout may include more than one transaction, so keep the provider's reconciliation detail rather than matching totals by appearance.
Unknown charges belong on a follow-up list. They should not become zero-cost assumptions just to complete a calculator.
Test the records as well as the checkout screen
Use each provider's supported test environment and test credentials. Check the success, failure and cancellation paths, the server notification or webhook, and the order status produced by each result. A success message in the browser is not enough if the order remains unpaid in the backend.
Where the test environment supports refunds or payout simulation, match those records to the original test transaction. Sandbox activity does not move real funds and may not reproduce every live risk or settlement decision.
After the integration is ready, a separate authorised small live payment is needed to verify real processing and settlement. Confirm receipt in the merchant account and the corresponding order state. Record refund behaviour separately, using the provider's current rules and the actual transaction details.
Add payment options at a pace you can support
One or two suitable methods can keep reconciliation and support manageable. More methods may serve additional customer preferences, but each can add configuration, failure states and refund procedures. Adding a button is not a guaranteed conversion improvement.
Choose based on the customers you can serve and the operational work you can maintain. For each method, record who investigates a failed payment, how the order is identified and how the customer receives an update.
Keep payment, payout and refund checks on the same handover checklist. That makes it possible to distinguish “the checkout worked” from “the order was recorded correctly” and “the money was received.”