J.P. Morgan and Thunes expand the cross-border payout conversation

The announcement

J.P. Morgan Payments announced an expansion of its cross-border capabilities with Thunes on 22 September 2026. Its announcement says the Xpedite Remit offering will support faster payouts to bank accounts and mobile wallets across more than 100 corridors, with access to local payment networks through a single account and connection. The bank identifies supplier payments, bill payments and remittances among the initial use cases. These are the provider’s stated capabilities, not a guarantee of availability for every business or recipient.

For merchants, the broader question is how an expanded payout network translates into a dependable operating process. The following analysis examines that question independently. It does not assume that FixPays provides this service, that a particular merchant is eligible or that every corridor has identical terms and performance.

Receiving money and sending it are different workflows

A business can have a successful checkout and still struggle to pay suppliers, creators or other counterparties. The inbound transaction and the outbound payment serve different purposes and may involve different providers. Before evaluating a payout product, a merchant should define exactly whose money is being sent, why the recipient is entitled to it and which entity is responsible for the instruction.

Consider a hypothetical marketplace that collects customer payments and later pays participating sellers. The relevant assessment is more detailed than whether the network reaches a seller’s country. The platform needs to explain its contractual role, the calculation of the seller’s entitlement, any deductions and the handling of refunds after a payout. Network coverage alone does not resolve those operational or legal questions.

A merchant paying its own overseas supplier may have a simpler structure, but it still needs reliable records. Purchase orders, invoices and receiving account information should connect to the payment instruction. Finance teams should be able to explain the purpose and beneficiary of a transfer without reconstructing the history from individual staff inboxes. Better preparation makes provider discussions more productive.

Read corridor coverage as a starting point

A statement about the number of supported corridors is useful for discovery. It is not a complete specification for a particular payout. Merchants should ask whether their originating entity, destination, currency, recipient type and transaction purpose are supported together. A route suitable for one combination may not establish availability for another, even when the destination country is the same.

The recipient’s chosen endpoint also matters. A bank account and a mobile wallet may have different data requirements and operational constraints. Merchants should request the relevant field definitions and validation rules, then design collection forms accordingly. Asking recipients for information that cannot be used creates friction; failing to collect required information produces avoidable exceptions later.

Coverage should be checked against actual business demand. A merchant can rank destinations by payout count, value and support effort, then focus its initial evaluation on the most consequential routes. This helps avoid a broad integration whose impressive geographic reach contributes little to the company’s real operations. A smaller, well functioning set of corridors may provide more immediate value.

Make the payment status understandable

Payout operations require a shared vocabulary. An instruction that has been received is not necessarily completed, and an error message may require a different action from a rejected recipient. Teams should agree on the states their provider returns and what each state means for the business. Customer facing communications should reflect those verified definitions.

A useful implementation exercise is to trace one payment through every available status. Record the responsible team, the expected notification and the evidence that the recipient can access funds. Identify which states permit a retry and which require investigation first. This prevents a support agent from sending a second payment simply because the first has not yet appeared in a dashboard.

Reconciliation should be designed at the same time. Each payout needs a stable internal reference connecting the recipient’s entitlement to the external transaction and the final accounting record. If a transfer is returned, the system should preserve that relationship. An operationally mature payout process can explain both what succeeded and what remains unresolved at the end of the day.

Faster execution needs careful exception handling

Speed can reduce waiting, but it also reduces the time available to correct an instruction before execution. Merchants should therefore put validation before submission. Confirm recipient details using an appropriate process, restrict who can edit sensitive payment fields and separate approval from creation where the organisation’s risk profile warrants it. These are suggested operational controls, not claims about the announced product’s configuration.

Changes to beneficiary details deserve particular attention. A legitimate supplier may switch accounts, while an impersonator may try to redirect a payment. Staff should verify changes through a trusted contact route already held by the business. A professional looking message should not, by itself, authorise a new destination. The control should work during busy periods and when the usual finance contact is absent.

Businesses should also rehearse the response to an incorrect instruction. Which support channel is used? What information must be supplied? Who can approve a further payment while the first is investigated? Recovery possibilities should be confirmed with the actual provider rather than assumed. Documenting the process before an incident makes the response more consistent and reduces improvised decisions.

Build the business case around recipient outcomes

A sensible comparison looks beyond the time it takes to submit an API request. Merchants should evaluate the recipient’s experience, the certainty of the amount received, the clarity of communications and the work required to resolve exceptions. Different recipient groups may value those outcomes differently. A supplier managing payroll and a creator receiving occasional earnings may have different priorities.

For an initial trial, select a manageable set of recurring payments and establish the expected result for each. Track successful completion, information requests, returns and support contacts. Compare the findings with the existing process using similar destinations and transaction purposes. Avoid treating a successful demonstration in one corridor as proof that every route will behave identically.

Commercial discussions should include the complete service terms, including conversion, deductions, funding requirements and support responsibilities where relevant. The provider announcement does not supply a bespoke agreement for a merchant. Obtain written details before making promises to counterparties, and build payout estimates around the arrangement actually offered to your business.

Accurate and timely recipient communication should always be included in the trial. Ask a small, appropriate group whether the payment reference is recognisable and whether the completion message matches their experience. If recipients repeatedly contact support despite technically successful transfers, the process still needs improvement. A merchant should also decide how it will communicate delays without giving unsupported arrival estimates. Clear, factual updates can preserve trust while an exception is investigated. Keep the communication template connected to verified payment states so that automated messages do not announce completion before the provider’s definition of that state has actually been met.