Skip to main content
When a Checkout Session returns an empty 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.
Either way the caller gets an SMS receipt, and your server learns the outcome from a 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 same checkout.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.