After the payment

This feature is not available on all Primer accounts. Contact your Customer Success Manager to receive access.

What happens once a payment has gone through: saving the card, charging it again without the customer present, and growing from a vault-only integration into Primer orchestration.

Save and reuse cards

Vault the card when you report the outcome, by setting vaultPaymentMethod: true on the resolve call:

curl -X POST https://api.primer.io/payment-attempts/{paymentAttemptId}/resolve \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "X-Api-Version: 2.4" \
  -H "Content-Type: application/json" \
  -d '{ "outcome": "SUCCEEDED", "vaultPaymentMethod": true }'

This is opt-in per payment: Primer doesn’t see the result of a proxied payment, so nothing is saved unless you say so in this call, and only once the outcome is SUCCEEDED. Primer returns a saved (multi-use) token, distinct from the single-use token the attempt started with. Store that token against the customer; it’s what you use for a saved card in the checkout and for charging the card later.

A returning customer in the checkout

Create the client session with the same customerId as before. The checkout shows the customer’s saved card (network and last four digits); they pick it and click Pay, with or without re-entering the CVV, depending on whether you’ve enabled recapture. The SDK creates a new single-use token from the saved card for this payment (the saved card itself isn’t consumed), and the flow continues exactly as in During the payment: your backend decides whether to approve or send the new token to the proxy.

CVV recapture

PCI rules mean Primer never stores a card’s CVV, so a saved token has no CVV field available. See Proxy reference. A returning customer can still supply a fresh CVV at checkout if you enable CVV recapture: the SDK exchanges it for a single-use token that carries the CVV like any other, which you can then send through the proxy with the CVV placeholder.

Charge a saved card without the customer

For a renewal, subscription charge, or other merchant-initiated payment, there’s no checkout and no client session. Your backend calls the proxy directly with the saved token, the same way it would call your PSP directly today.

curl -X POST https://proxy.primer.io/v1/payment_intents \
  -H "X-Primer-Api-Key: YOUR_API_KEY" \
  -H "X-Target-Host: api.stripe.com" \
  -H "Authorization: Bearer YOUR_PSP_SECRET_KEY" \
  -d "amount=1000&off_session=true&confirm=true&card[number]={{tok_saved_789.NUMBER}}&card[exp_month]={{tok_saved_789.EXPIRY_MONTH}}&card[exp_year]={{tok_saved_789.EXPIRY_YEAR}}"

Set whatever flag your PSP uses to mark the request as merchant-initiated (off_session and confirm for Stripe above), exactly as you would calling them without Primer. There’s no CVV placeholder available on a saved token; most PSPs don’t require it for a card already on file.

The network transaction ID (NTID) that some PSPs return from the first payment on a card, and expect on later merchant-initiated payments, isn’t stored by Primer Vault yet. If your PSP requires it for recurring authorization, keep tracking it yourself for now rather than relying on Primer to carry it forward.

If you also use Primer for orchestration (a processor connected and a workflow set up), the same saved token works with POST /payments instead of the proxy, so Primer runs the renewal’s full lifecycle, including retries:

curl -X POST https://api.primer.io/payments \
  -H "X-Api-Key: YOUR_API_KEY" \
  -H "X-Api-Version: 2.4" \
  -H "Content-Type: application/json" \
  -d '{
    "orderId": "order-124",
    "amount": 1000,
    "currencyCode": "USD",
    "customerId": "customer-456",
    "paymentMethodToken": "tok_saved_789",
    "paymentMethod": { "paymentType": "SUBSCRIPTION" }
  }'

The same token works both ways. Pick whichever one you want for a given renewal, and switch for the next one if you need to.

Move traffic to Primer

This is optional, for merchants who want to grow from a vault-only integration into Primer processing some or all of their payments.

Because every payment already runs through the same client session, checkout, and token regardless of where it’s processed, moving traffic to Primer is a routing change, not a re-integration:

	Stays the same	Changes
Client session	`customerId`, `orderId`, amount, currency	Nothing, you’re already creating it this way
Checkout	The card form, the approval event	Nothing
Your backend	Nothing	Where you send the decision made in Decide where the payment goes: call `approve` instead of sending the request through the proxy
Primer account	Nothing	A processor connected and a workflow configured, so there’s somewhere for `approve` to route to

A practical way to start is with a share of traffic rather than a full cutover. Pick a rule you already use to decide where payments go (one card network, one issuer country, one customer segment) and route just that slice to approve while everything else keeps going through the proxy. Compare the results against what your own PSP was doing, then widen the share once you’re satisfied.

​Save and reuse cards

​A returning customer in the checkout

​CVV recapture

​Charge a saved card without the customer

​Move traffic to Primer

Save and reuse cards

A returning customer in the checkout

CVV recapture

Charge a saved card without the customer

Move traffic to Primer