cards array, there is
nothing to charge yet. send_link texts the caller a secure pay link so they pay on their own
phone, never reading a card number aloud. It is the first-time path in both integration modes, and
once they pay they are recognized on every call after, at any Ringup
merchant.
The whole path
1
Open a session when the order is ready
create_checkout resolves the amount and returns cards.2
Find no card to offer
cards is empty, so there is nothing the caller can approve on the call.3
Ask, then text the link
Send the link only after the caller agrees to the text.
Response
The session is the only input
send_link takes one field: checkout_session_id. The caller, merchant, amount, and policy
already live on the session, so passing them again could only introduce a disagreement. That makes
a pay link trustworthy: it can never carry a total no real order produced, or be texted to a
number the session was not opened for.
Check sent before you speak
sent is false when a repeat send inside a short dedupe window returned the same link without
texting again. Duplicates are common: platforms retry slow tool calls, and models fire twice.
Read the field. An agent that treats a 200 as proof a text went out tells the caller “I have
texted you” when nothing did. On false, say the link was already sent and point them at the
earlier message.
A caller whose link genuinely never arrived and who asks again seconds later is outside the window
and gets a fresh text, so resending always works.
During the call or after
Payment can complete either way:- During the call. The caller pays while still on the phone. Poll the session so your agent knows the moment it clears and can close the call with the order paid.
- After the call ends. The caller hangs up and pays later from the same link. The call does not have to wait.
checkout.succeeded webhook. A link payment is not a separate event, so one
handler covers both a saved-card charge and a first-time link payment.
After a first payment made with a typed card, that card shows up in cards on the next session
and you can charge it directly.
Apple Pay and Google Pay, included
The pay page also takes Apple Pay and Google Pay, with zero integration work on your side. One wallet button renders based on what the caller’s device supports, the wallet sheet supplies their name and email so they type nothing, and the payment lands on your server as the samecheckout.succeeded event with wallet set to apple_pay or google_pay.
A wallet payment is pay-now only: the merchant’s processor does not allow a wallet payment to be
saved as a card on file. So a caller who pays by wallet is recognized by name on their next call,
but has no chargeable card; the agent texts them the link again and they tap the wallet again.
Only a typed card becomes a saved card the agent can offer on a future call.
Next steps
Charge
The recognized-caller path: run a saved card without a link.
Webhooks
A first-time link payment lands as checkout.succeeded too.