Fixed a number of regex in OpenAPI schema, so that they comply with OpenAPI standard.

We have added new custom metadata fields for Payments and Payouts

Custom metadata allows you to include additional information with each transaction, giving you more flexibility and
control over your payment processing. You will soon be able to define your own routing rules based on this metadata, optimizing payment
processing and improving customer satisfaction.

To add custom metadata, use the Create a Payment
or Create a Payout endpoints.

Send the metadata as name-value pairs, where the name is the field name and the value is the data you want to associate
with that field.

Example

{
    "customMetadata": {
        "customer_type": "VIP",
        "order_id": "1234567890"
    }
}

Limitations

• You can send a maximum of 25 name-value pairs per transaction.
• Each key or value can be up to 200 characters long.
• Keys can only contain alphanumeric characters, hyphens, underscores, commas, and spaces.
• Leading and trailing spaces are not allowed in keys.

Validation Errors

The following new errors are associated with custom metadata validation failures

• Custom Metadata validation errors

Important Notes

• Security: Custom metadata is not encrypted.
• Availability: This functionality is available to all merchants.
• Scope: Custom metadata is only considered for the initial payment request in 3DS transactions and is ignored in any
  subsequent 3DS requests.
• Refunds, voids, and captures do not support custom metadata
• Retrieval: You can retrieve the custom metadata associated with a transaction using
  the Get Payment Status
  or Get Payout Status endpoints.
• Custom metadata is currently not supported for Hosted Payments Page

Additional Information

• For more detailed information and examples, please refer to the complete API documentation.
• If you have any further questions, please contact customer support.

Added Create PayPal Order endpoint

We have added a new POST endpoint to our API: [POST /v1/paypal/orders], that will create an order with PayPal and return the order ID.

We have added new 'Merchant' risk instrument

We have added the ability to indicate if a card has been externally tokenized, and if the token has been used when performing a payment

We have added the option to receive payouts using a card's PAN

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.