Skip to main content
If the Network Tokenization API fails, you’ll receive an error in the format of the following example:
Some errors include a details array containing field-level information, including a location (the camelCase property name that caused the error) and a message describing the issue. This information doesn’t contain PAN or cardholder data and is safe to surface to end users. For example, a ValidationFailed error always includes details:

Why Tokenization Can Fail

The API Error Details table below outlines each error code and the recommended next action you should take after receiving it. Keep in mind as you review these recommendations: a tokenization request can be rejected by the card network or the issuing bank, and the response doesn’t necessarily tell you why. Networks and issuers exclude the specifics to prevent bad actors from learning what tripped a card. As a result, an error like IssuerDeclined can cover several causes, including a fraud lock, a lost or stolen card, or a card the issuer can’t verify. If the card network sends more detail, we pass it in the message field.
Improve your tokenization success rateIncluding the card’s CVV2 value and billing address (at minimum, postal code) in your /tokenize request can reduce CardVerificationFailed and InvalidParameter failures. CVV2 is optional on every network, so leaving it out won’t cause a decline on its own, but if you send it, it must be correct; an incorrect value triggers an error.See the /tokenize endpoint documentation for field details.

HTTP Response Codes

What endpoint you call determines the types of HTTP response codes you can potentially receive. This table outlines the types of errors you can receive:

API Error Details

Every error response includes a requestId field in the response body. When contacting Pagos support about any error (not just 500s), include this value to help us quickly locate the relevant logs. If you send an X-TRACE-ID header with your request, it will be used as the requestId in the response.