> ## Documentation Index
> Fetch the complete documentation index at: https://primer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# After the payment

> [!NOTE]
>
> 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](https://primer.io/docs/vault/during-the-payment.md#report-the-outcome), by setting `vaultPaymentMethod: true` on the `resolve` call:

```bash theme={"dark"}
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](#a-returning-customer-in-the-checkout) and for [charging the card later](#charge-a-saved-card-without-the-customer).

### 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](https://primer.io/docs/vault/during-the-payment.md): 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](https://primer.io/docs/vault/reference.md#proxy-reference). A returning customer can still supply a fresh CVV at checkout if you enable [CVV recapture](https://primer.io/docs/payment-services/save-payment-methods.md#recapture-the-cvv-of-saved-cards): 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.

```bash theme={"dark"}
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.

> [!NOTE]
>
> 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`](https://primer.io/docs/api-reference/v2.4/api-reference/payments-api/create-a-payment) instead of the proxy, so Primer runs the renewal's full lifecycle, including retries:

```bash theme={"dark"}
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

> [!NOTE]
>
> 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](https://primer.io/docs/vault/during-the-payment.md#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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.