payment_required when you create a Checkout Session. The merchant
changes the rule with no redeploy.
The three values
When you create a Checkout Session,payment_required comes back as one of:
It is per purchase, not per merchant
The same merchant can produce different values on different orders. A parts shop might make payment optional under $50 and required above it. That is why the session resolves the amount before the verdict, and why the answer cannot be cached across calls.none is the graceful floor
none has two possible meanings, and you never have to tell them apart:
- The merchant has no processor connected. There is nothing to charge on. This is not an error:
creating a session for an unconnected merchant returns
201withpayment_required: "none", andtransfer_toisnull. - The merchant’s policy says this purchase does not need payment. A business that takes payment at pickup, or an order under a threshold that the merchant chose to let through.
payment_required alone, with no separate
“is this merchant set up yet” check, makes one agent configuration safe to run in front of every
merchant on your platform, connected or not, from day one.
Whoever runs the payment branches on
payment_required: in hosted mode Ringup’s payment step
reads it off the Checkout Session; in the in-agent API path your agent reads it and decides whether
to charge. Either way the merchant’s rule, not your code, decides.Next steps
Send Link
What happens when a first-time caller has no saved card.
Charge
Running a recognized caller’s saved card directly.