Skip to main content
When a card payment is declined, the card processing platform returns an error code and a short message. This page lists the codes observed in production, explains what each one means, and gives the action we recommend for your customer.
Note: The message in the Message returned column is passed through exactly as the processing platform sends it, in English. The list below is built from refusals observed in production — the platform may return other codes that are not listed here. If you hit one, contact support with the order reference.

Error codes

Use your browser’s find (Ctrl / Cmd + F) to jump to a code.

Handling patterns

Most of the codes above fall into one of the following patterns. If you only implement one behaviour per pattern, implement these.
-2019, -2006, 100, 103, 106, 110, 111, 116, 120, 121, 125, 903, 100700, 100827, 341016 and 341025 are refusals of that specific card: insufficient balance, limit reached, blocked card, wrong number, or an issuer refusal. Show the refusal and invite the customer to pay with a different card. Do not reveal why the issuer refused beyond what the table suggests.
-2013 and -2007 mean the order itself is finished — the attempt budget is spent, or the session expired. Retrying the same payment_id will keep failing. Create a new payment instead.
100801 means the card network never answered within the timeout, so the outcome is genuinely unknown — the customer may have been debited. Always check the final state of the order with Verify Payment before offering a retry.
-2018, 76, 910, 151018, 151019, 341017, 341019, 341020 are timeouts or unreachable-service errors on the bank or platform side. Show a “please try again shortly” message rather than a refusal.
341018, 341022, 341023, 341024, 342034 mean the customer cancelled or let the 3-D Secure step time out. The card is fine. Offer to restart the payment without suggesting anything is wrong with their card.

Recurring payments error codes

The Recurring Payments endpoints report refusals with the HTTP status below and a code: in result.error on Create, in message on the other endpoints. A field that fails validation on Create is returned as {"<field>": ["<reason>"]} without a code. These are API-level refusals, not card declines. Two refusals happen on the customer’s side, in the Flouci app, and never reach your API: consent_required (the app did not present the current consent text) and subscription_not_payable (the first charge is no longer payable, for example after you canceled). Both leave the subscription untouched.