[go: up one dir, main page]
Processing cutover
Developer Documents‣Processing cutover

As part of our ongoing commitment to improve service for our merchants, we’re switching transaction processing for some of our key acquiring banks to connect via new direct integrations. This will allow us to provide even better and more responsive support on processing queries.

This cutover is designed to be as seamless as possible. Most integrators will not need to make any changes; existing API requests will continue to be accepted as they are today. A small number of informational fields in API responses (including transaction retrieval responses, notifications and in-flight callbacks) will differ slightly after we update a merchant’s configuration. The values affected should generally not be relied upon by existing integrations, but full details are provided below.

We’ll be rolling out the new routes in phases and contacting affected merchants prior to cutting over their accounts. For more information on your current acquiring routes, please raise a support call.

Updated response elements

The processing element returned in API responses will vary in a few places according to the processing route in use:

API Response
{
…
processing {
authResponse {
…
statusCode string
Acquirer response code for the transaction. This should generally be the same for a given outcome.
message string
Acquirer message for the transaction.

This will be message text as returned by the acquirer (or issuer) where possible; otherwise, a descriptive message mapped from their response code. For some acquirers, this value may start to contain a more specific reason for declined transactions.

You may use this message when manually reviewing a transaction to find out what happened, but you should not code your implementation to rely on it.
gatewayReference string
Processing engine reference for the transaction. This should always be treated as an opaque string.

We may use this reference if you ask us to investigate what happened to a transaction.
gatewayCode string
Processing engine status code for the transaction.

This field will no longer be returned in most cases. Your implementation should not be coded to rely on this field or its value.
gatewayMessage string
Processing engine message for the transaction. The contents of this field will change – it may consist of the acquirer message, or another, internal message.

You may use this message when manually reviewing a transaction to find out what happened, but you should not code your implementation to rely on it.
…
}
route string
Transaction processing route. This will change from “PAYON” to “CPE”.
}
…
}
Comparison of response elements
Before After 

HTTP/1.1 201
{
  "processing": {
      "model": "MANAGE",
      "authResponse": {
          "statusCode": "00",
          "acquirerName": "Barclays Merchant Services",
          "message": "Approved - no action",
          "authCode": "070604",
          "gatewayReference": "111gbpeb29d9e7e5653e2FMeeee10z00",
          "gatewayCode": "000.000.000",
          "gatewayMessage": "Transaction succeeded",
          "avsAddressCheck": "FULL_MATCH",
          "avsPostcodeCheck": "FULL_MATCH",
          "cv2Check": "MATCHED",
          "status": "AUTHORISED"
      },
      "route": "PAYON"
  },
  ...
}


HTTP/1.1 201
{
  "processing": {
      "model": "MANAGE",
      "authResponse": {
          "statusCode": "00",
          "acquirerName": "Barclays Merchant Services",
          "message": "AUTH CODE:860813",
          "authCode": "860813",
          "gatewayReference": "f3764ae8fd3ed723f55bf9d4500b973c",
          "gatewayMessage": "AUTH CODE:860813",
          "avsAddressCheck": "FULL_MATCH",
          "avsPostcodeCheck": "FULL_MATCH",
          "cv2Check": "MATCHED",
          "status": "AUTHORISED"
      },
      "route": "CPE"
  },
  ...
}