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:

Charge bearer code	Description
`OUR`	All transaction charges are to be borne by the ordering customer. A list of currencies which guarantee the `OUR` option can be shared.
`SHA`	All transaction charges other than the charges of the financial institution servicing the ordering customer account are borne by the beneficiary customer.
`BEN`	All transaction charges are to be borne by the beneficiary.

ISO20022 Endpoints (pain.001)

When using the pain.001 endpoint:

Charge bearer code	Description
`CRED`	All transaction charges are to be borne by the creditor.
`DEBT`	All transaction charges are to be borne by the debtor.
`SHAR`	For credit transfers: Transaction charges on the sender side are borne by the debtor, transaction charges on the receiver side are borne by the creditor. For direct debits: Transaction charges on the sender side are borne by the creditor, transaction charges on the receiver side are borne by the debtor.
`SLEV`	Charges are applied following the rules agreed in the service level and/or scheme. Typically equivalent to `SHA`/`SHAR`.

Charge Bearer Processing

We process charge bearer instructions based on two key factors:

Your charge bearer configuration
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.