> ## Documentation Index > Fetch the complete documentation index at: https://docs.interchange.io/llms.txt > Use this file to discover all available pages before exploring further. # Paying by card > Save a card once as your organization's payment method — no commitment, paid features turn on right away Adding a card is the fastest way for your organization to start using paid features. You save it once, on the [Plan & Billing page](/v2/buyer/billing/plan-and-billing), and it becomes your organization's payment method — there is no checkout step, no plan you must pick first, and no commitment. ## What "add a card" does When an org admin adds a card on **Settings → Plan & Billing → Payment & invoices**: 1. The card details are collected in a secure form embedded in the page. Card numbers are encrypted in transit and **never stored on Scope3 servers** — Scope3 keeps only the card's brand, last four digits, and expiry date, for display. 2. If your bank requires it, a quick verification step happens right in the form (you may recognize this as the confirmation prompt your bank uses for online purchases). 3. Once the card is verified, it becomes the organization's payment authority, and paid features turn on — **immediately, before any charge is made**. You do not wait for a first invoice. The card belongs to the **organization**, not to the person who added it. Only org admins can add, replace, or remove it. ## When the card is charged Nothing is charged when you add the card. Charges happen automatically on the billing cycle, in arrears — you use paid features first, and the cycle's charge covers what was used, with the invoice attached to your receipt. There are no card processing fees added to what you pay. If your organization would rather receive invoices and pay on net terms — purchase orders, AP portals, bank transfer — that path is always available: choose **Set up invoicing** instead. Both paths lead to the same Plan & Billing page, and you can switch between them later. Larger organizations often pick the card too: it skips vendor setup on both sides. ## If a payment fails If a charge fails, Scope3 retries automatically on a published schedule and emails you at every step — you don't need to do anything unless a retry fails too: | When | What happens | | ------------- | ---------------------------------------------------------------------------------------------- | | Right away | Email: the payment failed, with a link to update your card | | 3 days later | First automatic retry | | 7 days later | Second (final) automatic retry, with an email warning that the account will be restricted soon | | 10 days later | If still unresolved: the account is **restricted** | | 30 days later | If still unresolved: paid entitlement lapses to the free tier | **Restricted means limited, never locked.** While restricted, new paid activity is paused — new intelligence-credit spend, new media commitments, new subscriptions or upgrades. Everything else keeps working exactly as before: * Your data, reports, and dashboards * Data export * Media that is already delivering (a card hiccup never pauses delivery mid-flight — that would create make-goods and harm the seller) * This page and updating your card — the fix-your-card flow is never gated by the problem it exists to fix **Recovery is self-serve and instant.** Update your card, then either wait for the next automatic retry or click **Update card & pay now** to retry immediately. The moment the charge succeeds, the restriction lifts and full access returns — no waiting on Scope3. The timings above are the defaults; Scope3 can adjust them for specific accounts without a product change. ## Updating or removing the card * **Replace** — add the new card the same way; it becomes the payment method and the old one is discarded. Do this any time, including before the old card expires. * **Expiry** — when your bank reissues a card, the saved card usually updates automatically with no action from you. When it can't, Plan & Billing shows an "expires soon" badge and you get an email about 30 days before the expiry date — a heads-up, not a restriction: an expiring card with no failed charge never blocks anything on its own. * **Remove** — allowed when nothing depends on the card. If it is your organization's only way to pay, removal is blocked with a pointer to add a replacement first (or set up invoicing) — otherwise paid features would turn off. ## For agents The saved payment method appears in the [billing account document](/v2/buyer/billing/tasks/get-billing-account) as `payment.paymentMethod` — kind, brand, last four digits, expiry, and status. When an organization has no payment method and needs one, the document's `nextAction` is `ADD_PAYMENT_METHOD`. Card entry itself is always a human step (it happens in a secure form), so agents hand that moment to a person — and there is a dedicated task for exactly that handoff. ### Requesting a card via your agent (`add_payment_authority`) An agent working on the organization's behalf requests a payment method with the `add_payment_authority` MCP task, in three steps: 1. **Request** — call with `action: "request"`. The task stages the request and returns a single-use `confirmationToken` (valid 5 minutes). Nothing is created yet. 2. **Confirm** — call again with `action: "confirm"` and that token. The task returns `{ method: "capture_link", url, status, expiresAt }` — a secure link valid for 30 minutes that serves one verified card capture. The URL is returned exactly once; the agent saves it and hands it to the person who holds the organization's card. 3. **The cardholder opens the link** in any browser — no account or sign-in is needed; the link itself is the authorization. The page shows which organization requested the card and the same secure embedded form as Plan & Billing. Card details go directly to the payment processor and never pass through the agent or the Scope3 API. The agent then polls `action: "status"` (every 15–30 seconds is plenty) until the status is `verified` — at which point the organization has an active payment authority and paid features are on — or `expired`, in which case it requests a fresh link. The link statuses are `pending → opened → verified`, with `expired` as the terminal didn't-complete state. Behind the capture page sits one public endpoint, `GET /api/v2/capture-links/{token}`: the hosted page exchanges the link token for the embedded form's credentials (and marks the link opened), and polls it with `?view=status` while verification completes. The token is the sole authorization — unknown tokens return nothing about any organization, and requests are rate-limited. Requesting a link requires org-admin access or an org-scoped service token; the task is available on both the buyer and storefront MCP servers because Plan & Billing is org-level regardless of role. Two more `nextAction` values cover the failure/recovery path above: * `RESOLVE_HOLD` — the account is restricted (day +10 in the table above). Resolved by `POST /api/v2/billing/payment-methods/pay-now`, which retries the outstanding charge on the org's saved card immediately. The route returns `processing`; poll the billing account document and watch `nextAction`/`standing.holds` for confirmation rather than inferring success from the response (the actual recovery is confirmed server-side, asynchronously). * `UPDATE_PAYMENT_METHOD` — a soft nudge shown when the card is inside the expiry lookahead window. It never gates anything on its own; it resolves the same way as `ADD_PAYMENT_METHOD` (replace semantics). `standing.holds` on the billing account document lists any active holds — today only `PAYMENT_FAILED` — each with a `reason` and `createdAt`. ## Related Where the card is added and managed The document that carries the payment method and next action