Paying with points and a card, step by step

Our previous article was An AI agent can apply a discount code. It can't yet spend a member's points. It said the open standards for agent checkout have a frame for paying with more than one instrument, but no points instrument to put in it. This article covers what that instrument has to do in a split-tender order, paid partly in points and partly by card.

More than one sequence works. Ours follows one rule: nothing irreversible happens until both the points and the card are secured. We'll show it, then the alternatives, following one purchase from our demo: a $149 enameled cast-iron skillet, with 500 points toward it and a card paying the rest.

One sequence

Settings a program manager configures are marked Configurable.

Before the transaction

1. Available balance. The agent asks the program what the member can spend: the balance minus any points already on hold for other orders.
2. Apply. The member tells the agent how many points to use. In our demo they type it: "Redeem 500 points on this order." Configurable: the minimum redemption, 500 points in the demo.

The transaction

3. Quote. The program converts 500 points to $5. Configurable: the redemption rate, 100 points to the dollar in the demo.
4. Hold. The program places a hold on 500 points against this order.
5. Consent. The member approves the whole order, with both payments shown.
6. Authorize. The merchant's checkout authorizes $144 on the card. If anything fails from step 4 to here, the hold is released and the authorization voided. The member keeps every point.
7. Capture. Once the order completes, the held points are redeemed and the card is captured. In our demo, StellarBack, our rewards layer, runs the hold and the capture. Exactly 500 CRWD go back to the program's issuer and are removed on chain. Configurable: the asset the points are minted as. CRWD is the demo program's own branded asset, closed-loop, so it moves only within the program.
8. Accrue. The card earns on $144 of qualifying spend. The $5 paid in points earns nothing. Configurable: the earn rate, one point per dollar in the demo.

Make capture idempotent. Capture can't be undone, so a retry or duplicate message must not redeem the same points twice. Each redemption carries an idempotency key, and a second capture with the same key changes nothing.

Accrue on what the card paid. If the checkout quoted what the order would earn, that quote is recalculated on $144, not $149, and the member sees the new figure before the order completes. A card earns on what it's charged; an agent comparing cards by earn would otherwise overstate every one. And earning on spend the program's own points paid for would add points liability for spend it has already funded.

Other sequences that work

Authorize first, then hold. After the member consents, the card can be authorized before the points are held. If the hold then fails, the checkout voids the authorization. We hold first because releasing a points hold is internal to the program, while a voided card authorization can stay pending on the member's account for a few days.

Deduct first, keep the code. Some store loyalty apps use redemption as a discount: the points are deducted when a single-use discount code is issued. If the order fails, the points stay spent, but the shopper keeps the code for next time. That bends the rule: the value survives as a code. As a price cut, not a second payment, it needs no accrual rule. But the store has to run both the points and the checkout, so it doesn't fit points held by a bank or card issuer.

What never works is capturing either side before the other is secured, leaving the member nothing if the other fails.

How the merchant is paid in full

The card's share settles through the merchant's acquirer as usual. The points share is funded by the program, under a settlement agreed with the merchant in advance. That settlement deserves its own article.

A common way to pay with points online avoids the question, and it's what this sequence replaces: the card is charged the full price, and the points come back later as a statement credit, so the checkout never shows the points.

What didn't carry over to agent checkout

Payment providers already take partial payments with gift cards: the gift card is authorized for its balance, the card pays the rest, and the order is cancelled if the remainder fails. That's the sequence above, in web checkout today. What didn't carry over is the interface. UCP's split-payments extension, released in v2026-08-25, standardizes the frame, but no released agent checkout standard defines the instrument that would carry the hold and the capture.

Agent checkout also adds two things. No shopper clicks through the steps, so the order the member approves has to show the points, not just the price. And the points program often isn't the merchant, so the hold, capture and accrual cross a boundary a store's own loyalty app never had to.

What our demo shows, and what it doesn't

The split-payment chapter runs through the program's own AI assistant on the Stellar testnet, where CRWD is a test asset with no monetary value. It shows the totals, the points held and the redemption on chain. Nothing is charged, so there's no card authorization, and the recalculated earn quote isn't in the footage. Our agent checkout chapter is different: there, points stay in a separate wallet agent's ledger, off chain, and its footage predates the accrual rule, so it earns on the full $149. These are the steps as we've built them, not proof anyone will buy them; we're testing that now.

You can watch the split-payment chapter, or the whole demo.