Skip to main content
Whether an order needs payment is a merchant setting, not logic in your agent. Ringup resolves it per purchase and returns it as 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 201 with payment_required: "none", and transfer_to is null.
  • 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.
Either way, respond the same: do not transfer, do not offer a card, carry on and end the call normally. That is why they share one value. Branching on 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.