Where Startups Can Build in Southeast Asian Cross Border Payments

A payment can be successful while the merchant’s work is unfinished. The sale still needs to match an order, appear in the right settlement report and reach the person responsible for the accounts. If the customer asks for a refund, another process begins.

That is a useful place to look for startup opportunities in Southeast Asia’s cross-border payments. Faster payment connections can support products for merchant reconciliation, customer support and industry-specific operations. The opportunity depends on the actual corridor, participating providers and customer workflow. “Regional payments” is too broad to be a product brief.

Our assessment is that founders should begin with a narrow operational problem around an available payment connection. Announced infrastructure can inform a roadmap, but customers need a service that works with the providers and payment flows available to them today.

Separate live payment links from future infrastructure

Three developments show why the distinctions matter. They involve different users, different payment experiences and different stages of delivery.

The DuitNow–PayNow linkage announced by Bank Negara Malaysia and the Monetary Authority of Singapore went live on 17 November 2023 for person-to-person fund transfers using identifiers such as mobile numbers. It followed a separate QR payment linkage launched in March 2023. A transfer to a person and a tourist’s payment at a merchant are not interchangeable use cases.

In another corridor, the Bank of Thailand announced a Thailand–China QR payment launch on 30 October 2025. The announcement describes users of Alipay, UnionPay and WeChat Pay paying participating Thai merchants. That stated direction should not be read as proof that every Thai customer can pay every Chinese merchant through the same arrangement.

Nexus sits at a different stage. The Bank for International Settlements describes Nexus as a model for connecting domestic instant payment systems through a standardised connection, reducing the need to build each bilateral link separately. Its project work was handed to Nexus Global Payments following that organisation’s incorporation in 2025.

In its February 2026 technical operator announcement, Nexus Global Payments named a PayNet and NETS joint venture and set a target of going live in 2027. As of this article’s research date, that is a rollout target, not evidence of a service already available to every regional customer.

For a startup, these differences shape what can be sold. A future network can justify preparation and partner conversations. It cannot substitute for a confirmed production route when promising a merchant a launch date.

Define a corridor before defining a regional product

Start with the payer’s country, the merchant’s country, the payment method and the direction of travel. Then identify the provider that can actually support the transaction and the merchant’s eligibility to use it.

Consider an illustrative product for a Thai retailer serving visitors from China. The first questions concern the participating payment providers, merchant onboarding and the shop’s point-of-sale workflow. An online seller accepting international orders would need a separate assessment. A payment option that works at a physical checkout should not be assumed to support an online checkout or a recurring subscription.

This is a research discipline as much as a technical one. Ask merchants to walk through recent transactions and show where staff have to leave one system to check another. Record which problems recur, who resolves them and what happens if nobody does.

A founder can then define a useful initial promise: help this type of merchant match these payments to these orders. That is easier to validate than a promise to simplify payments across Southeast Asia.

Reconciliation offers a concrete place to start

A transaction record, a settled balance and a bank payout answer different questions. Product teams should understand those differences before designing a single green “paid” status.

Xendit’s reporting documentation, published in July 2026, provides a practical provider example. It distinguishes transaction reports from balance reports and auto-withdrawal reports. Money coming in can initially await settlement; settled movements and bank payout reconciliation appear in different reporting views. Its documentation also explains how foreign-currency transactions are represented in settlement currency. These are Xendit’s documented conventions, not a universal specification for every provider.

The product opportunity is to make such information usable in a merchant’s existing workflow. A finance team may need to connect an order reference to a provider transaction, its fees and the eventual payout. A shop manager may only need to know which sales require attention before closing the day.

Begin by identifying the decisions each user needs to make. A dashboard that displays more payment data is not necessarily useful. A clear exception queue, with enough evidence to resolve each item, may be easier for a merchant to value.

Keep traceability in the design. If the system marks an order as reconciled, the operator should be able to see the underlying records and understand the match. Where the records disagree, show the disagreement rather than hiding it behind a confident summary.

Design refunds and failures before expanding coverage

A checkout demonstration usually follows the successful path. Merchants also deal with customers who close an app too early, uncertain payment status, duplicate attempts and refund requests. Those situations require more than a generic error message.

PayNet’s DuitNow QR documentation distinguishes domestic, inbound cross-border and outbound cross-border flows. It also documents reversal services involving cases such as refunds, disputes and timeouts. Founders should check the applicable corridor and provider implementation rather than assume that every payment flow exposes identical functions.

Build an exception map with the provider. For each case, agree what the merchant sees, what evidence is available, who can act and how the customer receives an update. Record the distinction between a request being submitted and the money actually returning.

An illustrative tourism booking tool might need to connect a cancellation to both a booking record and a payment reference. If it cannot confirm the refund status, it should explain the next step and identify the responsible support team. A reassuring but inaccurate message can make a difficult service interaction worse.

Access and operating responsibility belong in the business model

An available network does not mean that every startup can connect directly or offer every payment service. Founders need to establish their role with the relevant payment providers and obtain appropriate advice for the services and markets involved.

Before building, confirm who contracts with the merchant, who handles funds, who performs required onboarding checks and who responds when a payment is disputed. Then make sure the commercial agreement and customer-facing product describe the same division of responsibility.

This is particularly important for software businesses adding payments to an existing product. Customers may assume that the company whose logo appears on the screen can resolve every payment issue. A support handoff should be designed before that assumption is tested by a real problem.

Sell an operating improvement that merchants can measure

The value proposition should fit a person’s working day. For a multi-outlet retailer, it might be less time matching sales and settlements across locations. For a travel operator, it might be clearer tracking of payment exceptions against bookings. These are hypotheses to test with customers, not claims of results already achieved.

Measure the current process first. How many items require manual investigation? How long do they remain unresolved? How much staff time goes into preparing a daily close? Use the same definitions during a trial so that the comparison is meaningful.

Pricing should reflect the problem being solved and the work required to serve the account. A subscription for reconciliation software and a transaction-based commercial arrangement have different economics. Model provider costs, onboarding effort and support demand before choosing either. High transaction volume can still produce a weak business if every exception needs manual intervention.

Distribution also deserves an early test. An existing point-of-sale vendor, accounting partner or industry software provider may offer access to the right merchants. Establish what that partner will actually do: introduce customers, integrate the product, train staff or handle support. Access to a customer base is useful only when there is a workable route to adoption.

Questions founders ask

Is Nexus already a live regional payment option

The February 2026 announcement set a 2027 go-live target. Treat that as a planned milestone and verify subsequent operating announcements before making customer commitments. Existing bilateral payment links need to be assessed separately.

Does a startup need to build another wallet

Not necessarily. A startup can investigate merchant software around reconciliation, payment exceptions or industry workflows, working with appropriate providers. Whether that becomes a viable business depends on customer demand, access arrangements and the responsibilities attached to the service.

Southeast Asia’s payment connections create useful infrastructure for founders to study. The sharper opportunity begins where a specific merchant still loses time, lacks visibility or struggles to serve a customer. Follow Global Apex Tech’s startup coverage and newsletter for more analysis of how regional technology changes translate into practical business decisions.