Response Codes

HTTP Status Codes

Successful responses

• 200 Ok: status informing that the transaction was successfully completed, such as the completion of a payment transaction, for example.

• 201 Created: status informing that the creation of the transaction occurred correctly for the methods that require the creation before the commit.

Client error responses

• 400 Bad Request: indicates some failure in executing the transaction, such as a transaction denied by the issuer, for example.

• 401 Unauthorized: indicates authentication error.

• 404 Not Found: the server did not find the requested resource. It may be a wrong endpoint or, in case of querying transactions, the transaction may not exist or may have been created in a different store than the one requesting it.

• 405 Method Not Allowed: the HTTP method is incorrect for the resource called (POST, PUT, GET, PATCH, DELETE), check the corresponding documents and verify that the method is the right one.

Server error responses

• 500 Internal Server Error, 502 Bad Gateway ou 503 Service Unavailable: may be returned in some internal failure or brief unavailability of the Gateway, we recommend contacting support to understand the reason.

Response codes

Negative Response codes (Routing via SiTef)

In routings via SiTef, you may receive negative response codes (for example, "-211"). In cases like this, please contact our support team.

Response code structure

Transactions denied with 255 "Transaction Denied" will have the reason categorized according to their origin indicated by the "denied_transaction_origin" field.

• denied_transaction_origin = 1 or 2 (internal denied): the search must be made in the Table Fiserv API Denied Transactions
• denied_transaction_origin = 3 (denied issuer): the search must be mande in the Table ABECS

Response example

{                                                                                                                                                   
    "code": "255",
    "message": "Transaction Denied",
    "payment": {
        "authorizer_code": "14",
        "authorizer_message": "VERIFIQUE OS DADOS DO CARTAO",
        "status": "NEG",
        "nit": "d112022b0eef24f55325de9bfbce8ad44969cc0765de757f76ae0e330464dd0c",
        "order_id": "2223",
        "authorizer_id": "2",
        "acquirer_id": "229",
        "acquirer_name": "Bin (Via Servicos TEF)",
        "merchant_usn": "123456780",
        "esitef_usn": "250205751361530",
        "sitef_usn": "000005",
        "host_usn": "001000078",
        "amount": "100",
        "payment_type": "C",
        "terminal_id": "ES000001",
        "denied_transaction_origin": "3",
        "payment_date": "05/02/2025T10:11",
        "recurrency_tid": "MPLI583AE0205"
    }
}

Table Fiserv API Denied Transactions

Response codes with the origin field: "denied_transaction_origin = 1 or 2", are specific to transactions denied due to internal Fiserv errors and will be handled by the Fiserv team itself.

Retries: For transactions denied under response codes corresponding to denied_transaction_origin = 1 or 2, we suggest following the retry recommendation provided in the table.

ABECS Table

Response codes with origin "denied_transaction_origin = 3" are specific to issuer denials. The ABECS table provides specific details about the error codes related to this origin.

Retries: For transactions denied under response codes corresponding to "denied_transaction_origin = 3", we suggest following the retry recommendation provided in the ABECS response codes table

• Reversible: a new attempt is recommended
• Irreversible: a new attempt is not recommended

Response Code Mastercard

Mastercard has implemented a new service where transaction denials submitted by issuers can be grouped by Mastercard and responded to under the following response codes:

Merchant Advice code (MAC)

For better authorization performance, Mastercard recommends that Acquirers and Merchants consider the MAC (Merchant Advice Code) code along with the response codes received.

The MAC provides additional details about the nature of the transaction and recommends what action should be taken in terms of retry, as indicated in the table below: