Gett Developer Portal
  • Welcome
  • Distribution Partners
  • Brand Partners
  • Commerce Partners
  • Ecosystem Partners
  • Errors
  • API Reference
Documentation
  • Get Started
  • Marketfront SDK
  • API Reference
Resources
  • Payments
Company
  • Gett
  • Terms of Service
  • Privacy Policy

Copyright 2026 Gett. All rights reserved.

409 Conflict403 Forbidden500 Internal Server Error400 Bad Request404 Not Found429 Too Many Requests503 Service Unavailable401 Unauthorized502 Bad Gateway422 Unprocessable EntityCATALOGSET_NOT_FOUNDCATALOGSET_REQUIREDCLIENT_CONTEXT_REQUIREDCLIENT_IP_INVALIDCLIENT_USER_AGENT_INVALIDITEM_UNAVAILABLEMODIFIER_REQUIREDORDER_TOTAL_DIFFERENTPRECISION_EXCEEDEDCARD_EXPIREDCARD_LOST_OR_STOLENINCORRECT_CVCINSUFFICIENT_FUNDSPAYMENT_DECLINEDPAYMENT_FAILEDPAYMENT_TOKEN_INVALIDPROCESSING_ERRORSESSION_USER_REQUIREDSTORE_CLOSEDSTORE_NOT_FOUND
powered by Zuplo
Errors

PROCESSING_ERROR

PROCESSING_ERROR

The payment could not be processed because of a temporary fault somewhere in the processing chain — a terminal, gateway, or processor timeout, or an unreachable issuer. No decision was made about the card.

Summary

FieldValue
Appears aserrors[].code
ResponseHTTP 200 — Order with isValid: false and a populated errors[]
Retry the same cardYes — after a short delay, and only after checking for an existing payment

This is a reason code, not a top-level error code

PROCESSING_ERROR is an errors[].code value on the order. It is not a top-level ProblemDetail.errorCode, so it carries no HTTP status, errorCategory, or retryable field of its own. See Unified OrderError shape.

When This Fires

  • POST /v1/marketfront/orders/place — payment processing failed transiently rather than being declined.

Recommended Action

This is the only payment reason code where retrying the same card is honest advice. Everything else in this group is a decision about the card; this one is a fault in the machinery.

  1. Wait briefly (1–3s with jitter).
  2. Resubmit POST /v1/marketfront/orders/place with a fresh Idempotency-Key. You received a response, so that attempt is finished — see Idempotency for the rule and why replaying the old key cannot work here.
  3. After 2–3 failed attempts, stop and offer a different payment method or ask the customer to contact their issuer.

Re-attempting is not free — this code carries a real charge risk

A processor or terminal timeout is precisely the case where the authorization may already have succeeded at the processor even though the order came back failed. A fresh-key re-attempt can therefore charge the customer twice, and no Idempotency-Key can prevent it — our idempotency record covers our order, not the processor's authorization.

Retry at most 2–3 times, and reconcile first where you can. If a customer reports a charge for an order you never saw succeed, treat this code as the likely cause and contact support with the requestId.

Do not describe this to the customer as a decline. The card was never refused, and sending them to find a different card is the wrong instruction for a fault that will likely clear on its own.

Example

Code
{ "isValid": false, "errors": [ { "code": "PROCESSING_ERROR", "message": "We couldn't process your payment right now. Please try again in a moment.", "pointer": null } ] }
PAYMENT_TOKEN_INVALIDSESSION_USER_REQUIRED
On this page
  • Summary
  • When This Fires
  • Recommended Action
  • Example
JSON