How to Receive Cross-border Payments via Alipay: A Guide for Merchants on Onboarding, Reconciliation and Team Management

If your products or services target Chinese consumers, whether to integrate Alipay often hinges less on “can you collect payments” than on whether your operating entity, sales regions, settlement arrangements and order system work together. For cross-border sellers, the steps where mistakes most often happen are usually: treating a successful payment as already settled, failing to reconcile refunds and chargebacks, letting several people share one merchant backend, or being unable to find the matching order and owner when funds look wrong.

Here is the takeaway: assess Alipay-related collection capabilities as one complete funding chain. What you need to confirm is merchant onboarding, supported payment methods, order creation and result notification, settlement currency and cycle, the refund process, and day-to-day reconciliation responsibilities. An API or a partner service provider is only part of how you connect; it cannot replace these operational and financial preparations.

First, separate “who you collect from” from “how funds are settled”

Cross-border collection is often treated as one problem, but it actually has at least three layers:

• How consumers pay;
• How the merchant creates orders and receives payment results;
• In which currency and on what cycle incoming funds reach the business account.

Independent sites, travel services, digital products or offline retail aimed at Chinese consumers may care more about whether an Alipay payment entry matches user habits. When serving wallet users across multiple markets, you need to evaluate whether an aggregated payment solution can cover different mobile payment methods. Alipay+'s public developer documentation describes it as a merchant-facing solution for accepting multiple payment methods (see the Alipay+ Merchant-presented Mode Payment integration overview); the markets, wallets, entity onboarding and fees actually available should follow what is agreed when you sign, not another seller's setup.

So do not rush to look for a “payment code” or API first. Write down your transaction model clearly: who you sell to, on which site or at which store the payment is completed, who creates the order, who prices the currency, who approves refunds, and which business account the money finally enters.

Four types of materials to prepare before onboarding

Payment providers usually review information around the merchant entity and transaction authenticity. The documents required can differ by region, industry and cooperation model, but sellers should at least organize the following:

Preparation item	What to explain	Why it matters
Business and operating info	Registered entity, beneficial owner, business address, website or store	Used for merchant onboarding and risk review
Product and fulfillment info	Product category, price, shipping or service delivery method, refund rules	Helps judge whether the transaction chain is complete
Collection and settlement info	Quoted currency, collection account, settlement entity, finance contact	Avoids mismatches between payer, account and contract entity
Technical and order info	Domain, callback URL, order number rules, test environment	Lets payment results return to the correct order

Pay special attention to whether the product descriptions, contact details, shipping notes, privacy policy and refund terms on your site correspond to each other. Even if the technical integration is done, incomplete business information will make later review, dispute handling or fund verification harder.

When choosing an integration path, compare capability boundaries, not slogans

Common paths include signing directly, going through a payment service provider, or reusing a platform's existing payment capability. No single path suits every seller. Compare them with these four questions:

1. Are your sales markets and the payment methods your buyers commonly use within the supported scope?
2. Is your order volume, average order value and refund frequency suited to the current settlement arrangement?
3. Can your existing store pass along a unique order number and reliably receive asynchronous payment results?
4. Can finance match payment records, refund records and actual bank-in records?

Official payment documentation usually splits steps into “create payment,” “user completes authorization or payment,” “receive result notification,” and “query the final status.” During integration, do not judge order completion only from front-end page redirects. Rely on the final transaction status defined by the service provider, plus its notification and query mechanisms, and design handling rules for network timeouts, duplicate notifications and users abandoning payment.

Manage order status and the shipping action separately

Many sellers' biggest reconciliation gap is treating an order as shippable the moment the payment page returns success. A safer practice is to split the payment chain into four statuses you can verify:

1. Order created: the store generates a unique order number and locks the amount, currency and product information;
2. Buyer paid or authorized: the front end shows a result, but you still wait for server confirmation;
3. Server confirms success: update the order only after a valid notification is received or the terminal state is queried;
4. Fulfillment and settlement tracking: shipping, cancellations, refunds and actual settlement each leave a record.

With this split, support can answer whether a buyer's payment has arrived, the warehouse can decide whether to ship, and finance can trace which order a given payment belongs to at month-end. Do not treat screenshots, chat records or browser prompts as the only proof.

Look at three ledgers at the same time when reconciling

Cross-border sellers should at least put three kinds of data into one reconciliation sheet: the order system, the payment backend, and the business account or settlement report. Reconcile daily or on a fixed cadence based on volume:

• Whether order number, order amount, currency and payment status match;
• Whether each successful order has a corresponding payment record or transaction reference;
• Whether refunded, partially refunded and cancelled orders return to the store in sync;
• Whether fees, FX or other adjustments between settlement amount and order amount are explained;
• Whether orders still incomplete beyond the expected time are routed to a manual-handling queue.

Your reconciliation sheet does not need to be complex at the start. What matters is that every discrepancy has a status, an owner and a next action. Labels such as “waiting for async notification,” “waiting for refund completion,” or “bank deposit awaiting match” are easier to follow up than a generic “anomaly.”

How to leave a trace for refunds, disputes and unusual orders

A refund is not an afterthought to a successful payment; it directly affects inventory, revenue recognition and customer experience. For every refund, keep the original order number, reason, request time, approver, amount and final status; for partial refunds, also record the remaining refundable amount. When a customer claims they paid but the order has not updated, query using the order number and transaction reference first; do not let support change order status based on a screenshot alone.

When you see prompts about unusual logins, identity verification, payment limits or suspicious transactions, use the official verification and appeal channels provided by the service provider and keep the related order, contract and fulfillment evidence. Do not handle funding problems by sharing verification codes, using someone else's identity documents or trying to bypass security checks; such practices expose business assets and customer data to greater risk.

When multiple people operate, control backend permissions and the working environment first

A collection backend is often used by operations, support and finance at the same time, but each person does not need the same permissions. We suggest assigning “initiate refunds, export statements, change settlement information, view orders, handle customer inquiries” to different roles and keeping at least two authorized owners of the business. When someone changes roles or leaves, promptly revoke access to the backend, business email, device sessions and recovery methods.

If the team needs to maintain several stores, markets or authorized payment merchants at once, the main thing to watch is not letting many people crowd onto one computer or one default account to operate the payment and settlement backends; otherwise it is hard to say who did what during reconciliation and handover. In that case, you can use PurpleMark to create isolated browser environments for different business roles, so members responsible for different stores or markets each log into their own merchant backend, avoiding mixed cookies, downloaded statements and accounts; when handover is needed, you can also confirm the handler and records by environment. Note that this environment isolation only makes backend logins and operating boundaries clearer; it does not replace the payment platform's authentication, compliance review or security verification.

A one-page checklist before going live

Before you officially enable payments, confirm with operations, engineering and finance together:

• Whether product price, currency, tax and refund terms are clearly shown on the front end;
• Whether a test order can run end to end from order placement, payment, notification to order update;
• Whether duplicate notifications, timed-out payments, cancellations and refunds have clear handling logic;
• Whether payment records, store orders and settlement reports can be linked by the same order number;
• Who can handle refunds, download reports and change settlement data, and who reviews them;
• Whether evidence and a point of contact are ready when an unusual transaction or review request appears.

FAQ

Can a personal account be used directly as the collection account for a cross-border store?

It depends on the service you use, the operating entity, the region and the business type. For a cross-border store run continuously, use the merchant entity and settlement account accepted by the service provider you sign with, and keep the contract, store information and funding flow consistent.

Why does the money not arrive immediately after a successful payment?

The payment result, refund window, risk-control review and settlement cycle are different stages. First check the order's final payment status, then review the provider's settlement rules and report; do not equate the front-end “payment complete” notice with money already credited to the business account.

Can collections from multiple stores be managed in one process?

You can unify order numbering, reconciliation sheets and permission management, but store entities, settlement data and authorization scopes should stay clearly separate. Unified management does not mean funds belonging to different stores can be mixed.

Conclusion

The point of receiving cross-border payments via Alipay is not finding the fastest payment entry, but closing the loop among merchant onboarding, order status, reconciliation, refunds and team permissions. Getting one traceable test order working before gradually expanding payment methods and markets is usually easier than integrating a complex flow all at once when it comes to controlling risk and cost.