Hosted Stored Payment Method → Off-session Sale

PROTOTYPE ONLY. Sandbox only. Card data belongs only in Elavon's hosted modal. Credentials stay server-side. A returned reusable token is forwarded once from the browser callback to server memory; it is never rendered, logged, or persisted.

Question: Can the smallest hosted-first path create a Stored Payment Method after explicit consent, then approve one separate server-initiated Sale with no new card entry?

Operator access

The token remains in this page's memory and is sent only as an Authorization header.

1. Give consent and prepare the hosted Sale

The initial CIT indicator is deliberately omitted because public documentation does not settle whether this flow requires C01 or 000.

2. Enter the test card only in Elavon's modal

On Approval, this page sends only an explicit allowlist of result, invoice, amount, transaction, and token-status fields. PAN, CVV, expiry, names, and addresses are never sent to the local server. The reusable token is not returned by the server.

3. Submit one later Off-session Sale

This action uses only the Stored Payment Method in server memory. It sends no card number, CVV, or expiry. It cannot be retried in this server process.

Current proof state

Ready.

Phase
ready
Initial invoice
—
Initial result
—
Stored Payment Method
not available
Off-session invoice
—
Off-session result
—
COF indicator
M01 — merchant-initiated unscheduled ad-hoc

Sanitized server evidence

No protected state loaded.

Portal correlation

  1. Find the initial invoice above in Payments and confirm the $1.16 Approval.
  2. Find its Converge-managed record in Card Manager, if the sandbox portal exposes it.
  3. Find the later invoice and confirm its $2.00 Approval and matching transaction identifiers.