When initiating payments through Banking Circle's APIs, you have several configuration options available to customize how your payments are processed and routed.

This article covers the key options you can specify when initiating payments:

• Charge bearer configuration
• Purpose codes for specific countries/currencies

Charge Bearer

A charge bearer code determines how transaction charges are distributed between the sender and beneficiary. By default, payments are sent with charge bearer SHA.

You can specify other charge bearer values, such as OUR or BEN. Whilst we support these values, we cannot always guarantee that they will applied as instructed, as they may be overridden by the payment rail used to execute the payment.

Note: This feature must be enabled for you to use charge bearer values other than SHA. Contact us to request activation.

Available Charge Bearer Options

The charge bearer options available depend on the payment initiation method used:

Standard API Endpoints

For single, bulk and agency/correspondent banking payment initiation endpoints:

ISO20022 Endpoints (pain.001)

When using the pain.001 endpoint:

Charge Bearer Processing

We process charge bearer instructions based on two key factors:

1. Your charge bearer configuration
2. The payment rail selected for execution

The system will either:

• Carry forward your instructed charge bearer value, or
• Overwrite it based on scheme requirements

For example, the SEPA Credit Transfer scheme only allows the SHA charge bearer. If you instruct a payment with charge bearer OUR, but our routing logic determines the payment should be executed via SEPA Credit Transfer, the charge bearer value will automatically be overwritten to SHA.

We will not reject a payment if the charge bearer is not supported by the payment rail used to execute the payment.

Tracking Charge Bearer Changes

You can monitor both the instructed and actual charge bearer values through:

• The GET /api/v1/payments/singles endpoint
• Reconciliation reports
• The outgoing payment processed webhooks (see Webhooks payload examples)

These values are exposed through two properties:

• instructedChargeBearer: Your original instruction
• chargeBearer: The final value used for execution

While a payment remains in 'Pending processing' status, the chargeBearer value matches the instructedChargeBearer.

Purpose Codes

Some countries, currencies and rails require purpose and category codes in the payment instruction. This requirement enables beneficiary banks and government authorities to effectively process, monitor and categorize incoming payments.

CNH to China

For CNH payments to China, setting a purposeCode is mandatory. Payments without a valid purpose may be rejected, delayed or subject to additional charges.

The purposeCode is supported via Client Portal and API. While there is no direct support for instruction via SWIFT, the value is automatically converted to Field 72 in the outgoing MT103 messages.

Supported values purpose:

SAR to Saudi Arabia

The Saudi Arabian Monetary Agency (SAMA) requires a purpose of payment for funds transfers to Saudi Arabia. This is a free-format text field with the following requirements:

• Format: SWIFT standard (140 characters, 4 lines, 35 characters each)
• Language: English only
• Restricted characters: Cannot use !@#$%^&_()?/>\<":|}\{+=_-.

For clients instructing via Client Portal or API, please populate this information within the 'Remittance Information' field within line 1.

For clients instructing via SWIFT, populate the purpose in Remittance Field (field 70) on line 1.

Note: Transactions submitted without a purpose of payment in Payment Details (SWIFT Field 70) may be held and ultimately rejected.

All currencies to United Arab Emirates

Payments to UAE accounts from abroad must satisfy two requirements:

1. Include a payment purpose
2. Use IBAN format for beneficiary account

The payment purpose should be included in the remittance information field (Field 70) with the following format: /BENEFRES/AE//POP/<3-character-code>/ or /ORDERRES/AE//POP/<3-character-code>/

Note: Transactions submitted without a purpose of payment in Payment Details may be held and ultimately rejected by Banking Circle's correspondent bank or the ultimate beneficiary bank.

For the complete list of valid UAE purpose codes, refer to the Central Bank of UAE documentation.

Refunds via Wero

Wero is a European mobile payment system launched on 2 July 2024 by the European Payments Initiative. It replaces or unifies several national payment schemes, like Giropay in Germany, Paylib in France, Payconiq in Belgium and Luxembourg, and iDEAL in the Netherlands. It is positioned as a real-time payment alternative to services like PayPal.

Our platform automatically supports incoming Wero payments with no additional configuration required. However, if you want to return funds to a customer’s Wero wallet (i.e., issue a refund), you must explicitly set the appropriate Wero Category Purpose (CPC) and Purpose of Payment (POP) codes.

These codes ensure the refund is recognized correctly within the SEPA Instant Credit Transfer (SCT Inst) framework and routed back to the user’s Wero wallet.

Required Codes for Wero Refunds

When initiating a refund to a Wero wallet, include the following:

These properties are mandatory for refunds via SCT Inst and ensure proper categorization, compliance, and interoperability as Wero integrates across European payment systems.

Payment tracking

To ensure the end-to-end ID of the original payment being refunded is carried through to Wero, you must include it in line1 of the remittanceInformation object (see Single payments) in the following format:

• /ROC/E2E ID//, replacing E2E ID with the actual ID (up to 32 characters long).