We have added merchantTransactionId to the request and response of the POST /payments endpoint. This is your unique
identifier for the API request that can be used when a connection issue occurs, and you don't receive a paymentId. We
will validate the uniqueness of the merchantTransactionId value per retail channel. If a payment/payout/refund is
created with merchantTransactionId abc, no other payment/payout/refund can be created with abc. If this happens we
will return an HTTP Status 409 Conflict with a 4701 response code.

The merchantTransactionId is a contract between BR-DGE and a merchant. This field will not be mapped downstream to any
PSP.

We have also added a new GET payments endpoint to our API which requires a merchantTransactionId as a query parameter,
this endpoint will return a payment in a list structure. If no payment can be found relating to this
merchantTransactionId, we will return an HTTP Status 200 and an empty list.

Added the pspName field to RawPspResponse inside the PspInfo response object.

See the following endpoints for more information on the PspInfoobject.

• Create a Payment

We have added merchantTransactionId to the request and response of the POST /payouts endpoint. This is your unique
identifier for the API request that can be used when a connection issue occurs, and you don't receive a paymentId. We
will validate the uniqueness of the merchantTransactionId value per retail channel. If a payment/payout/refund is
created with merchantTransactionId abc, no other payment/payout/refund can be created with abc. If this happens we
will return an HTTP Status 409 Conflict with a 4701 response code.

The merchantTransactionId is a contract between BR-DGE and a merchant. This field will not be mapped downstream to any
PSP.

We have also added a new GET payouts endpoint to our API which requires a merchantTransactionId as a query parameter,
this endpoint will return a payout in a list structure. If no payout can be found relating to this
merchantTransactionId, we will return an HTTP Status 200 and an empty list.

We have relaxed the requirement to provide a value for PSP in a payout request. If your retail channel is configured to use only one PSP, then we will default to use that to process the payout.

If there are multiple PSPs configured then a PSP should still be provided in the payout request. If omitted you will receive a 4000 response code.

We have added a new GET refunds endpoint to our API: [GET /v1/payments/{paymentId}/refunds], which will return a list of all the refunds
associated with a paymentId. Additionally, a merchantTransactionId can optionally be passed in as a query parameter to find a specific
refund on a payment.

We have changed the 5004 response code to be mapped to HttpStatus 422 instead of 500.

We have added cashierId field to the response of GET payment and payout status call. This field will be present in the
response in cases where the transaction was handled by a cashier.

We have added merchantTransactionId to the request and response of the POST /refund endpoint. This is your unique
identifier for the API request. We will validate the uniqueness of the merchantTransactionId value so if a
payment/payout/refund is created with merchantTransactionId abc, no other payment/payout/refund can be created with
abc. If this happens we will return a HTTP Status 409 Conflict with a 4701 response code.

This identifier will in future be used to retrieve a payment/payout/refund when you experience a connection drop and
are unable to obtain a paymentId.

We have added Paysafecard as a new payment-instrument, which can be used to make Payments via the PSP Paysafecard.

For more information, please see our Paysafecard integration page.

We have added a stand-alone Network Token Service Provider. You can now provision Network Tokens from multiple Card Schemes via a single integration with BR-DGE.

You can use BR-DGEs Network Token Service to:

• Create CoFs and have BR-DGE provision a Network Token.
• Provision a Cryptogram for use outside of the BR-DGE platform.
• Be kept informed of the status of your Network Tokens and whether they can be used.
• Delete existing CoFs and their respective network tokens.

For more information, please see our Network Token Service Provider page.