Swift payment

Swift payment, orchestrated — one API in front of every partner-bank SWIFT route.

topropay sits in front of SWIFT-member partner banks and exposes their reach through a single unified API. Send and track MT103 / ISO 20022 payments, route per corridor, surface gpi status end-to-end and reconcile every UETR into the same ledger as cards, wallets and crypto.

Book a SWIFT review Explore the platform
Sender Corr·1 Corr·2 Beneficiary MT103 :20: REF · :32A: EUR89,400.00 · :71A: SHA UETR · GPI TRACKER Sent Acc·Corr·1 In Corr·2 Credit
MT103 with end-to-end gpi tracker, surfaced to your dashboard.
200+
countries reachable via partner SWIFT members
gpi
tracker status surfaced end-to-end
ISO 20022
MX message support on the unified API

The short version

What the swift payment network is, and where topropay fits

What SWIFT is

SWIFT — the Society for Worldwide Interbank Financial Telecommunication — is the messaging network most international bank-to-bank payments run on. It's not a settlement system itself; it's how banks tell each other to move money. The dominant message types are MT103 (single customer credit transfer) and, increasingly, the ISO 20022 pacs.008 equivalent. SWIFT gpi adds a unique end-to-end transaction reference (UETR) and a tracker so the originator can see where the payment is in real time.

Where topropay fits

topropay doesn't operate as a SWIFT member itself — that role sits with licensed partner banks in the connected set. What the platform does is abstract those partner banks behind a single unified API, route per corridor, and surface gpi status events as first-class webhooks. The merchant gets the reach of several SWIFT-member partners and the operational shape of one integration.

Key benefits

What changes with swift payment processing through orchestration

Four outcomes that show up most consistently once SWIFT rails are run through the orchestration layer rather than direct against one bank.

  1. Reach

    Settle to almost any country on the swift payment network

    The SWIFT network reaches more than 200 countries through 11,000+ member institutions. Through topropay's connected SWIFT-member partners, a single integration can move funds into bank accounts across that footprint — without the merchant needing to hold a SWIFT BIC themselves.

  2. Tracking

    End-to-end gpi status, not a black box

    Where the underlying partner is on SWIFT gpi (and most are), the platform surfaces the gpi tracker UETR status through to your dashboard and webhooks. You can answer 'where is the payment' in seconds instead of a chase email to a correspondent bank.

  3. Routing

    Pick the right SWIFT route per transaction

    Routing weights consider corridor (sender country → beneficiary country), currency, ticket size and partner-bank pricing per corridor. A payment from EUR to MYR may route through a different partner than the same merchant's USD to BRL flow — chosen automatically inside the same API call.

  4. One feed

    SWIFT activity reconciled into the same ledger as cards

    MT103 confirmations, gpi status updates, fees deducted by correspondents and beneficiary credit confirmations land in the same normalised ledger as card receipts. Finance closes the month from one export, not 'cards plus bank statements'.

How it works

From API call to beneficiary credit, with gpi status surfaced throughout

Five stages between issuing a SWIFT payment from your back-end and seeing beneficiary credit confirmed inside the unified reconciliation feed.

  1. API call from your back-end

    Issue a SWIFT-rail payment instruction through the unified API — beneficiary, currency, amount, purpose code, regulatory metadata. The same call shape as a card authorisation, with rail-specific fields.

  2. MT/MX message generation

    The connected partner bank composes the MT103 (or ISO 20022 pacs.008) message with the correct field set, charge bearer and remittance information based on your call payload.

  3. Corridor-aware partner selection

    Routing picks the partner with the best landed cost and reachability for the corridor and currency. Where two partners cover the corridor, the routing engine compares against your own historical traffic.

  4. gpi UETR + status events

    The end-to-end UETR is captured at message send; status events from the gpi tracker (or partner equivalents) flow into webhooks until beneficiary credit.

  5. Settled / fees / beneficiary credit

    Settlement, correspondent fees deducted en-route and the final beneficiary credit confirmation roll into the unified ledger — keyed off the UETR for audit.

Main use cases

Where a swift payment platform earns its keep

Six merchant shapes that benefit from a SWIFT rail under orchestration, with the operational shape that fits each.

  • Cross-border B2B invoicing

    Invoices to overseas counterparties paid by wire on SWIFT, with end-to-end gpi tracking surfaced to AP/AR teams. The integration shape from your ERP is one API, not one per partner bank.

  • Marketplace seller payouts in fiat

    Cross-border seller payouts route through the SWIFT-enabled partner most suitable for the corridor. Per-seller reporting stays inside the same reconciliation feed as card and crypto payouts.

  • Treasury and intra-group transfers

    Multi-entity merchants move funds between corporate accounts in different currencies using the same orchestration as customer-facing rails. Compliance metadata stays attached to each leg.

  • PSPs and ISVs reselling bank-rail reach

    Resellers expose SWIFT-rail reach to their downstream merchants via topropay's unified API, with per-tenant reporting and per-tenant fee structures.

  • FX-aware large-ticket flows

    Large-ticket international payments choose between FX-at-send vs FX-at-credit at the connected partner; the chosen rate is logged on the UETR for finance reconciliation.

  • Compliance-heavy verticals

    Regulated financial services, licensed gaming operators and other compliance-bound merchants get sanctions screening, purpose codes and Travel Rule fields wired into the message composition step by default.

Message anatomy

Inside an MT103 — the fields topropay composes for you

The fields a SWIFT message carries shape what happens during the hop. The platform composes them from your unified-API payload and validates them before send, so correspondents don't repair (or return) what could have been right the first time.

:20: Sender's Reference
Unique reference for the payment — surfaces in the unified API as the merchant's own idempotency key.
:32A: Value Date / Currency / Amount
Settlement date, ISO 4217 currency, amount — the canonical money fields on the message.
:50K: Ordering Customer
Name and address of the originator; topropay enforces correct formatting and regulatory completeness on send.
:59: Beneficiary
Beneficiary account / IBAN and name; the platform validates the beneficiary against IBAN format and country rules before composition.
:70: Remittance Information
Up to 4 lines of unstructured text or structured remittance fields, depending on corridor and ISO 20022 alignment.
:71A: Details of Charges
OUR / SHA / BEN — picked from your unified-API call; defaults configurable per corridor in the dashboard.
:121: UETR
Unique End-to-end Transaction Reference — the gpi tracker identifier; auto-populated, surfaced in webhooks.

Platform features

Capabilities behind swift payment solutions on the platform

What the platform actually ships specifically for SWIFT rails — beyond the general orchestration features shared with other payment methods.

  • Unified payments API

    One REST contract for SWIFT rails, cards, wallets and APMs; SDKs for web, mobile and server.

  • MT / MX message composition

    Partner banks compose MT103 / pacs.008 messages from your unified-API payload; field validation happens client-side and pre-send.

  • ISO 20022 ready

    MX message support across the connected partner-bank panel; structured remittance fields preserved end-to-end.

  • SWIFT gpi tracker integration

    End-to-end UETR captured; gpi status events surfaced via webhooks and operator portal until beneficiary credit.

  • Corridor-aware routing

    Per-corridor (sender country × beneficiary country × currency) routing weights, scored against your own historical outcomes.

  • FX policy controls

    FX-at-send vs FX-at-credit per partner; locked rates logged on the UETR for finance reconciliation.

  • Sanctions & screening

    Sanctions screening on the originator and beneficiary before message composition; flagged payments rejected pre-send, not in correspondent.

  • Purpose-code & Travel-Rule fields

    Purpose codes, Travel-Rule fields (where applicable) and structured remittance attached to every message from your API payload.

  • Status & exception webhooks

    Signed events for accepted / in-flight / credited / returned / repaired / cancelled, mapped to a normalised status model.

  • Unified reconciliation

    SWIFT activity normalised into the same ledger as card and crypto receipts; daily exports keyed off the UETR.

Trust & compliance

Compliance posture for SWIFT-network access

SWIFT-rail compliance lives mostly in the partner-bank relationship — sanctions screening, AML monitoring, purpose codes, Travel Rule fields. topropay's posture is to enforce the relevant controls at the unified-API layer so the message that hits the network is clean on first send.

Partner-licensed SWIFT access
SWIFT-network access is delivered through licensed partner banks and SWIFT-member PSPs. topropay does not operate as a SWIFT BIC itself; it integrates with the partners that do.
Sanctions & AML
Sanctions screening on originator and beneficiary before message composition; AML monitoring scaled to merchant vertical and volume.
Purpose-code accuracy
Correct purpose codes per corridor enforced on the API call — incorrect codes are a common reason for correspondent-bank delay.
Data residency
Regional data-residency options where the partner bank and the merchant's regulator require it.
Licensed verticals only
Licensed gaming, regulated financial services and other compliance-bound merchants supported only where current operating licences exist. Grey and black-market verticals are out of scope regardless of rail.

Ready to send SWIFT

Send your first MT103 from the unified API.

A 30-minute SWIFT review walks through the corridors relevant for your traffic, the partner-bank panel behind them, and a sandbox to test the message-composition and gpi-tracker flow before any commercial commitment.

Book a SWIFT review Read the API docs

Frequently asked

Buyer questions about a SWIFT-orchestrated payment platform

Questions buyers ask before committing — covering SWIFT membership, message-level mechanics, gpi tracking, corridor reach and the practicalities of running SWIFT alongside other rails.

  1. 01

    Is topropay a SWIFT member or a non-SWIFT integration layer?

    topropay is a non-SWIFT integration layer that connects to SWIFT-member partner banks and PSPs. The platform doesn't hold its own SWIFT BIC — that role sits with the partner institution. From the merchant's perspective the integration is one API call; from the network's perspective the message is sent and received by the licensed partner.

  2. 02

    What does a swift payment actually look like under the hood?

    A swift payment is, in the simplest case, an MT103 (or, increasingly, an ISO 20022 pacs.008) message sent across the SWIFT network from the originator's bank, through one or more correspondent banks, to the beneficiary's bank. Each hop deducts its own fee, applies its own checks and forwards the message. SWIFT gpi adds an end-to-end UETR identifier and status tracker so the message's progress is visible to the originator.

  3. 03

    Why route swift payment processing through topropay rather than direct?

    A merchant that goes direct holds a relationship with one bank, gets one set of corridors at that bank's rate card, and lives inside that bank's portal for status. Swift payment processing through topropay lets the merchant ride several connected partner banks at once — corridor-aware routing picks the best per transaction, status is surfaced uniformly across all of them, and reconciliation is one feed.

  4. 04

    Does the platform reach the full swift payment network coverage?

    The swift payment network reaches more than 200 countries through 11,000+ member institutions. topropay's reach across that network is a function of the connected partner-bank set — the merchant dashboard shows the live corridor coverage and the partner behind each. We avoid publishing a static reach map because the matrix shifts as partner relationships evolve.

  5. 05

    How does this integrate with our existing card processing?

    The same unified API handles cards, wallets, bank rails and SWIFT. From your back-end, a swift payment instruction is a different call shape with rail-specific fields, but the surrounding plumbing — auth, idempotency, webhooks, reconciliation — is identical. SWIFT activity reconciles into the same ledger as card receipts.

  6. 06

    What does payment swift actually mean as a term — message or money?

    Payment swift in industry usage usually means a payment sent over the SWIFT network — most commonly via MT103, increasingly via ISO 20022 pacs.008. SWIFT itself is a messaging network, not a settlement system; the money moves through the relationships between the sender, the correspondents and the receiver. topropay's role is to make initiating and tracking that message a one-call experience.

  7. 07

    What's the difference between a swift payment gateway and a normal payment gateway?

    A normal payment gateway authorises card transactions; a swift payment gateway sits in front of a SWIFT-member bank and exposes a friendly API for SWIFT message composition, send and tracking. topropay behaves as a swift payment gateway by abstracting the partner-bank-specific message composition behind one unified API — same call shape regardless of which partner bank ultimately sends the MT103.

  8. 08

    Are there swift payment solutions tuned to specific verticals?

    Swift payment solutions on the platform layer vertical-specific behaviour on top of the shared rail: marketplaces get split-payout flows; B2B merchants get ERP-friendly reconciliation; treasury teams get intra-group rules and FX policy controls. The base rail is the same; the policy on top is what varies per merchant.

  9. 09

    What is a swift payment platform expected to do beyond just sending the message?

    A swift payment platform that earns its keep does five things beyond the bare message: validates the payload pre-send (IBAN, BIC, purpose code, charge bearer); composes the MT/MX correctly per corridor; routes across partner banks based on cost and reachability; surfaces gpi status as first-class events; and reconciles fees-deducted-en-route into the merchant's ledger keyed off the UETR. The bare MT103 is the easy part.

  10. 10

    Is the platform something a buyer might call a money swift gateway?

    Money swift gateway is the colloquial shorthand for a gateway that moves money over SWIFT — i.e. a swift payment gateway. topropay fits that description from a buyer's view, while delivering the SWIFT network access itself through licensed partner banks. The merchant's integration is with topropay; the underlying SWIFT membership is the partner's.

  11. 11

    And what about money swift payment gateway specifically?

    Money swift payment gateway is the longer form of the same idea — an API surface that lets a merchant initiate and track SWIFT-rail money movement without operating as a SWIFT member themselves. topropay delivers that pattern, with the additional benefit of orchestrating across several partner banks rather than locking the merchant to one.

  12. 12

    How does the platform handle gpi tracking and exceptions?

    Where the partner bank is on SWIFT gpi (the dominant case today), the UETR is captured at send and the gpi status events flow into webhooks until beneficiary credit. Exceptions — repairs, returns, cancellation requests, sanctions holds — map to a normalised status model so your back-end doesn't need partner-specific handling.

  13. 13

    How long do swift payments usually take?

    Speed depends on the corridor, the currency, the partner banks involved and any compliance review at intermediates. Many gpi-enabled corridors complete the same day; some same-currency / same-country payments arrive within minutes. Long-tail corridors can still take 1-2 business days. The gpi tracker surfaces realistic ETAs based on observed corridor behaviour.

  14. 14

    Can SWIFT activity be combined with our SEPA, Bacs and PIX flows on the same dashboard?

    Yes — SWIFT is one bank rail among many in the connected set. SEPA, Bacs, PIX, Interac and the rest sit alongside SWIFT under the same unified API, the same operator portal and the same reconciliation feed. The choice between SWIFT and a regional rail for a given payment becomes a routing-policy choice, not a separate integration.

Related

Related on the topropay platform