Send SWIFT Payments

Send international wire transfers to any bank worldwide via SWIFT. The platform handles message routing, correspondent banking and status tracking - you integrate one API and consume webhooks.

How a payment flows

You create the payment, the platform routes it through the SWIFT network to the correspondent bank, and every status change comes back to you as a webhook. The final outcome is confirmed by tracking the payment via the SWIFT Frontend API. Whether a payment needs approval before it goes out depends on the transaction signing setting of your tenant (see Before you send).

Without signing (default)
With signing
Rejected
Returned

Created → Sent to clear → Accepted → Completed

Created → To sign → Signed → Sent to clear → Accepted → Completed

Created → Sent to clear → RejectedCommon reasons: invalid or unknown BIC, insufficient funds, sanctions or compliance screening hit, message formatting errors, regulatory restrictions.

Original: Created → Sent to clear → Completed Return: separate credit transaction, created directly as Completed (type=Payment return)

A return never moves your original payment to Rejected - the original ends Completed, and the returned money arrives as a distinct Payment return transaction, so both stay visible and reconcilable.

Full status lifecycle, error flows and webhook reference: Payment statuses.

Before you send

Check the beneficiary bank

One call covers it all - Bank Information API (GET /v1/bank-info/{iban}) returns the bank’s BIC, name and a per-scheme reachability map including SWIFTCORE:

{
  "bic": "WESTGB2LXXX",
  "bankName": "Western Bank",
  "sepaSchemas": { "SEPAINST": false, "SEPACT": false, "SDDCORE": false, "SWIFTCORE": true }
}

Use it to validate the IBAN and confirm the beneficiary bank is a reachable SWIFT participant (SWIFTCORE: true). The same check also runs automatically during payment processing - a payment to an unreachable bank is rejected with a clear validation error instead of being sent.

Beneficiary bank BIC is resolved for you

You do not need to supply the beneficiary bank’s BIC - when the creditor account is an IBAN, the platform resolves the BIC from it automatically. Provide creditor.agentBic only when the account is not an IBAN.

Use idempotency

Always send an Idempotency-Key header when creating payments to prevent duplicates during retries.

Without idempotency, network retries can result in duplicate transfers.

Transaction signing (optional)

Signing is a per-tenant setting - it can be enabled or disabled for your account.Signing disabled (default): no approval step is needed - the payment goes straight out.Created → Sent to clear → ...Signing enabled: every payment must be approved before it is sent. It waits in To sign until approved via the sign, approve or decline APIs (or the PGW UI). Declining cancels the payment.Created → To sign → Signed → Sent to clear → ...

Create a payment

curl -X POST https://api.pgw-sandbox.finventi.com/v2/transactions/swift \
  -H "Authorization: Bearer {token}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: {uuid}" \
  -d '{
    "amount": 100000,
    "currency": "EUR",
    "priority": "NORM",
    "debtor": {
      "name": "Sender Ltd",
      "iban": "LT543210010000000003",
      "address": { "streetName": "Upes g.", "buildingNumber": "5", "postCode": "08303", "townName": "Vilnius", "country": "LT" }
    },
    "creditor": {
      "name": "Recipient Ltd",
      "iban": "GB82WEST12345698765432",
      "address": { "streetName": "High Street", "buildingNumber": "12", "postCode": "SW1A 1AA", "townName": "London", "country": "GB" }
    },
    "settlement": {
      "method": "INDA",
      "date": "2026-08-05",
      "iban": "LT111000011101001000"
    },
    "charges": { "bearer": "SHAR" },
    "remittance": "Invoice INV-2026-001"
  }'

{
  "result": {
    "id": 12345,
    "status": "Created"
  }
}

The full request and response schema - all fields, validation rules and examples - is in the API reference below.

Charge bearer

SWIFT transfers may incur correspondent bank charges. Choose who pays via charges.bearer:

DEBT

You pay all chargesBeneficiary receives the full amount

SHAR

Shared charges (default)Each party pays their bank’s fees

CRED

Beneficiary paysCharges deducted from the amount

Integration Checklist

Implement idempotency

Generate and persist Idempotency-Key for each payment

Check beneficiary bank reachability

Use the Bank Information API to confirm the beneficiary bank is a reachable SWIFT participant

Handle multi-currency

Specify source and target currencies correctly

Implement webhook receiver

Track payment status via webhooks

API Reference

Create SWIFT payment

POST /v2/transactions/swift - complete field documentation

Bank information

GET /v1/bank-info/{iban} - BIC and SWIFT reachability check

Sign transactions

POST /v1/transactions/signatures - sign payments waiting in To sign

Approve / decline

PATCH /v1/transactions/{id}:approve and :decline

Next Steps

Payment statuses

What happens after you send - every status explained

Cancel SWIFT payments

Stop a payment that should not go through

Getting Started

Integration Guide

Account Management

SEPA Instant/SCT

SEPA Direct Debit

SWIFT Payments

Payment Information

Investigations (Preview)

Nostro Accounts

Bank Information

Webhooks

How a payment flows

Before you send

Create a payment

Charge bearer

DEBT

SHAR

CRED

Integration Checklist

API Reference

Create SWIFT payment

Bank information

Sign transactions

Approve / decline

Next Steps

Payment statuses

Cancel SWIFT payments

​How a payment flows

​Before you send

​Create a payment

​Charge bearer

DEBT

SHAR

CRED

​Integration Checklist

​API Reference

Create SWIFT payment

Bank information

Sign transactions

Approve / decline

​Next Steps

Payment statuses

Cancel SWIFT payments

How a payment flows

Before you send

Create a payment

Charge bearer

Integration Checklist

API Reference

Next Steps