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 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.

We have added the 5305 response code description as:

Unknown outcome due to read timeout, please contact your processor.

We have added ignoreAvs parameter to the POST and GET /v1/payments API endpoint.

This parameter allows you to ignore the result of their Address Verification Service (AVS) and process the Payment regardless.

When tokenizing payment-instruments, we now return the underlying card metadata associated with the network token in the response.
This is useful to provide accurate and up-to-date reporting of payment instruments, for merchants who wish to use this information
within their payments workflows.