merchant_id when you
create a Checkout Session, and that one value decides three things:
the payment policy applied to the purchase, the processor the money
settles on, and which of the caller’s saved cards are chargeable. Who is calling is a separate
identity, see Caller Identity.
The dialed number is the merchant key
On a multi-tenant voice platform the number the caller dialed is the near-universal per-merchant key: one number per business, no per-agent configuration. Resolvemerchant_id from the dialed
number your telephony already gives you, and one agent serves a whole fleet of merchants.
merchant_id is the id Ringup issued when the merchant was created. If you run your own tenant
ids, keep a map from dialed number to merchant_id on your side, where the mapping is yours to
audit.
Why the merchant comes from the call, not the model
Fillmerchant_id from call metadata, in the code that assembles the request. A merchant id the
model composes can be mistyped, hallucinated, or prompt-injected by a caller, and it is the value
that chooses whose bank account the money lands in. It is not a value to leave to a sentence.
A merchant that has not connected a processor is not an error. The session comes back with
payment_required: "none", so the payment layer stays inaudible and the call runs normally. See
Payment Policy.Next steps
Checkout Session
Where merchant_id is passed, and what comes back because of it.
Payment Policy
What the merchant decides for each order: required, optional, or none.