Paying by card

Adding a card is the fastest way for your organization to start using paid features. You save it once, on the Plan & Billing page, 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: 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 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