Home

Overview

  • API REST

  • Web Checkout

    • Payment Link

      • Notifications

        • Automatic Retries

          • Return Codes

            • Merchant Web Page

              • 3D Secure 2.0

                • Acquirers Connections

                  • Payment methods

                    • Anti-Fraud Integrations

                      • Store Management

                        • General Information

                          Idempotencia REST

                          Overview#

                          Idempotence guarantees that there will be no duplication in sending transactions from CARAT to Acquirers/Issuers, since the transaction request will only be made once. Even if an identical request is sent repeatedly in a specific time interval, with this parameter (Idempotency) CARAT will validate whether it has already been processed. If the transaction has already been carried out and CARAT already has this response (approved or denied), it will not send another request, it will only inform the result of the previous processing, thus eliminating the query functionality (via OrderID/ or NIT). If for any reason (timeout, etc.) the transaction has not been processed, CARAT will then resubmit it and obtain a response.

                          Why use Idempotence:

                          When it comes to single-request transactional APIs, the inclusion of the idempotency_key in the header becomes a fundamental requirement. This approach guarantees the security and reliability of operations carried out through the platform. By adopting this practice, you will avoid unwanted duplications while improving the fluidity of transactions. This procedure results in a more efficient experience for both your system and end users.

                          Final Status

                          Idempotence will return the current status of the transaction. If the response returns ERR and NEG, they should not be retried with the same idempotency_key as these are transactions with completed status, and will not undergo status changes on query retries. The next request must be treated as a new transaction and a new idempotency_key.

                          StatusDescription
                          CONTransaction Confirmed
                          ERRTransaction Error
                          NEGTransaction Denied

                          We suggest the use of idempotence for situations in which there is a response with 502, and/or transactions with an invalid/time-out response.

                          Response Codes

                          CodeDescriptionFormat
                          1270Idempotent transaction body does not match the original< 80 AN
                          1271Processing idempotent transaction< 80 AN
                          1272Idempotent transaction is not of the same type< 80 AN
                          1274Idempotent nit transaction reversed does not match the original< 80 AN