Skip to main content
Billing determines how money reaches you when Interchange clears payments for your storefront. You enter your payout bank details once — on the Payouts tab of the Plan & Billing page, via PUT /api/v2/storefront/billing/payout-details, or through the set_payout_details agent operation — and Interchange pays you by bank transfer, net of the platform fee and any additional fees on your billing config. Setup is optional only for official Scope3 sales-adapter storefronts, where the downstream platform relationship already has an external settlement agreement. A third-party sales agent or a finished-product/pass-through source is still a normal storefront and does not change settlement. A normal storefront uses Interchange clearing, so payout details are required — but only to get paid. The billing_setup readiness check is advisory, not a go-live blocker: a storefront can activate and start transacting with payout details missing. Funds still accrue against every booking; they simply cannot be disbursed until payout details are on file. Add them any time from the Payouts tab, PUT /api/v2/storefront/billing/payout-details, or set_payout_details — activation never waits on this step. All examples use the storefront base URL:
Authenticate every request with Authorization: Bearer $SCOPE3_API_KEY.

​
Organization IU plan and Rate Card

Plan & Billing → Plan & pricing is the storefront view of your organization’s one Effective IU Rate Card. Buyer activity, storefront work, Murph, and every other IU-rated workload use the same plan, corporate pricing adjustment, rollover policy, and wallet. Your storefront does not have a separate plan. If your organization contracts a platform license for governance, integrations, support, or SLA, that license appears as an overlay on the same IU plan rather than another wallet.
The standard Organization IU Rate Card is published in staging for a controlled pilot and visible only to invited organizations. It remains unpublished in production until the pricing and governing terms are approved. Invited staging organizations can review and accept the exact Rate Card, including its 100-IU setup-credit terms. Enrolled organizations may also see the accepted included-IU allocation, observed usage, and a display-only forecast. Transactional balance drawdown, entitlement enforcement, invoices, payment collection, and renewal charging remain off. Existing accepted media-pricing arrangements are unchanged.
Without an active IU plan binding, a storefront can use the basic no-cost posture for pass-through to a third-party sales agent. This is not a named “Free” tier. The current staging-only pilot uses these planning values: These figures are the standard USD list, agreed on 2026-07-22 and not yet published in production. Prices are set per currency rather than converted, so a plan in EUR, GBP, or AUD is its own published number and not this figure at an exchange rate — read your own Effective Rate Card if it is not in USD. A corporate discount, a negotiated package, or an enterprise offer replaces the list entirely. Individual per-activity IU counts are separate and several remain under calibration. After a separate production billing launch, commitments will be billed at the start of each monthly period, while pay-as-you-go usage and committed-plan overages will be billed after the period. Staging publication and acceptance do not start those charges. Pay as you go provides no included monthly IU allocation. On a committed plan, unused included IUs carry into the next month up to 50% of the plan’s included quantity (125 on the 250 plan and 500 on the 1,000 plan), then expire; promotional credits never roll over. If your organization has an authorized corporate discount, the plan-selection task shows both list and effective prices before you confirm. That discount applies once across the organization; it is not a storefront-only discount. The same wallet funds buyer activity. An activated social account is 4 IUs per account-month, including mirror, read, write, routine sync, and up to 13 months of history; your accepted Rate Card is what prices it for you. Those account-months draw against the shared IU wallet and appear on Usage & credits. No money is charged for them yet — charging is switched on per organization, never silently. See Buyer social-account activity. When an effective Rate Card makes the offer available, a genuinely new seller billing account receives one automatic setup credit of 100 IUs when it completes storefront signup. The credit is valid for 60 days from signup and is a restricted lot inside the organization’s shared wallet: only eligible storefront setup work can use it. Storefront provisioning may finish asynchronously without moving that expiry window, and later storefronts do not create additional credits. It cannot fund buyer activity, general Murph use, or another workload, and it never rolls over or stacks. An optional promotion or referral code can attribute that same credit and may carry an authorized price or access adjustment, but it does not add another 100 IUs or change the setup credit’s value or expiration. The adjusted Effective Rate Card is shown before acceptance. Interchange issues these codes; storefronts cannot create them, and a referral code records attribution only—it does not promise a reward or payment. When an organization IU plan is active, the page shows its snapshotted prices and term. A later Rate Card or discount change does not rewrite those accepted terms. Contracts & orders → IU plan history retains each accepted binding, including its Rate Card version, list and effective prices, discount, acceptance source, and term. The same history appears from buyer and storefront entry points.

​
Accepting a private offer for the next term

If Scope3 issues your organization a negotiated private offer while an IU plan is active, an organization administrator can review and accept it for the next term. Plan & Billing shows the current plan and the upcoming offer separately, including the exact price, included IUs, overage, rollover, and effective date. Accepting the offer does not reprice, shorten, refund, or prorate the current term. The accepted offer starts when the current term ends and becomes the organization’s active IU plan at that boundary. No further action is required after acceptance. You can accept only one offer for an upcoming term at a time. After acceptance, you cannot change renewal or select another plan until the new term starts. If your organization has not been issued a private offer, nothing changes and no action is required. Standard public plans and private offers marked pin exact renew one month at a time on the exact accepted plan and price snapshots. Each renewal creates a new immutable history entry linked to the prior term. A newer Rate Card, a changed discount, or a private plan never silently replaces those terms; it requires the applicable notice and successor flow. A private offer marked review required does not auto-renew. While renewal processing is healthy, the new history entry normally appears about one minute after the monthly boundary; its effective start remains contiguous with the prior term. An organization administrator can choose End plan at term before the change cutoff shown in Plan & Billing. This does not shorten or refund the accepted term: the plan remains active through its displayed end date, then the organization returns to its no-paid-IU-plan posture because no automatic successor is created. Plan & Billing shows the pending non-renewal and exact effective timestamp, including timezone. Ending the plan is organization-wide because every IU-rated workload shares it. It does not terminate your platform agreement or change an existing accepted media-pricing arrangement. If you want to stop only storefront merchandising or another capability, disable that capability without ending the shared plan. Before the same cutoff, an administrator can reinstate automatic renewal. That reinstatement is recorded as a new audit event; it does not erase the earlier cancellation. Once the cutoff has passed or a successor term already exists, the prior term can no longer be changed. Scope3 operators can inspect the same history, but cannot bypass the governing agreement’s cutoff or rewrite an accepted term. Scope3 retains the complete renewal audit trail. The history beside the current controls shows the 500 most recent decisions. Each entry is labeled Renewal target or Earlier term, so an instruction from an earlier term cannot look like a decision affecting the term being managed. If the accepted plan cannot renew on its exact current terms—for example, because the Rate Card was terminated or a different discount now requires an explicit successor—Plan & Billing says automatic renewal is unavailable. It does not promise a renewal the billing worker cannot create. You can still record End plan at term; reinstatement becomes available only after the exact renewal is eligible again. The page also shows the next action supplied by the billing service. Choose an IU plan opens the shared organization plan-selection task after an effective Rate Card is published. If the governing Terms of Service have not been accepted, the Terms of Service action comes first. When Scope3 has set your organization up on standard terms but nobody has accepted them yet, Plan & Billing shows Accept the platform terms and get_billing_account reports plan.contractStatus: "awaiting_acceptance". The contract and any rate card negotiated at setup are real and take effect the moment an administrator of the organization accepts — Scope3 does not accept on your behalf. Until then the storefront cannot transact. Accounts that inherit the organization’s contract cannot accept for themselves; one administrator on the organization accepts, and its accounts are unblocked. Your confirmation applies only to the exact Rate Card version and prices shown. If that offer changes before confirmation, the task reloads the latest version and requires you to review and confirm it again. Only a verified organization administrator can accept. Buyer and storefront IU activity use the resulting same binding; existing accepted media pricing stays separate and is not changed by the IU plan. The task also offers Continue without a paid plan and Decide later. Continuing without a plan suppresses the automatic next-login prompt only for the exact Rate Card revision you reviewed; a successor revision may prompt again. Deciding later permits the prompt on your next login. Neither choice removes the manual Choose an IU plan action from Plan & pricing while the offer remains current, so you can return at any time.

​
How you get paid

Interchange collects payment from the buyer, deducts the fees on your billing config, and pays the remainder to your bank account by bank transfer in your payout currency. Payout runs are executed by the Interchange finance team — there is no self-serve withdrawal step, and you do not need to hold a balance anywhere. Each transfer carries a reference so you can reconcile it against your media buys. Today settlement is sequential: Interchange pays you after it receives the buyer’s corresponding payment, subject to the applicable payment terms. Each payout account clears one currency: for Interchange-cleared storefronts, your payout currency must match your storefront’s settlement currency (defaultCurrency). The settlement_currency_match readiness check blocks go-live on a mismatch.

​
Why Interchange needs your bank details

Bank details are how Interchange pays you — nothing else. A payout by bank transfer needs:
  • Beneficiary name (beneficiaryName) — the account holder exactly as your bank knows it.
  • Beneficiary address (addressLine1, city, postalCode, countryCode) — required by banks for international transfers.
  • Account number or IBAN (accountNumber) — where the money lands.
  • One bank identifier (bankIdentifierType + bankIdentifierValue) — a Fedwire/ABA routing number, CHIPS ABA, SWIFT-BIC, or local bank code, so the transfer routes to the right bank.
  • Payout currency (currency) — the currency your account accepts.
Interchange uses these details only to execute payouts. They are never shared with buyers and never appear in discovery or media-buy responses.

​
What happens to your bank details

  • Your account number is encrypted at the application layer (AES-256-GCM) before it is written to the database — the database never holds a usable plaintext value — with disk-level encryption beneath it.
  • The account number (or IBAN) is write-only: once saved, it is never displayed again. Reads — GET /billing, the get_billing_info operation, and Settings → Billing — return only the last four characters, so you can confirm which account is on file without exposing it.
  • To change accounts, submit the full payout details again; the previous details are replaced.

​
Multiple payout entities

If your storefront is a child account, it initially shows the organization’s primary payout details as a read-only inherited fallback. An admin of the child can open Settings → Billing → Payout entities and add an account-owned payout entity without receiving access to the organization’s other commercial billing data. The child’s first entity becomes its primary payout destination and takes precedence over the inherited fallback. If your organization is paid through more than one legal entity — say an India entity and a Brazil entity — register a payout bank account for each entity and payout currency via PUT /api/v2/storefront/billing/payees (the set_payout_payee agent operation, or Settings → Billing → Payout entities in the UI). Each payee carries its own beneficiary name and address, account number, and bank identifier:
  • One bank account per entity per currency. A payout account clears exactly one currency, so an entity paid in two currencies registers two payees. The entityName + currency pair identifies the payee; submitting the same pair again updates it.
  • The beneficiary name must match the account holder — the legal entity itself. Banks reject transfers where the beneficiary on the wire doesn’t match the name on the account.
  • Every payout destination is a payout entity, and exactly one is your primary. The details you set with set_payout_details are the primary entity — and like any other entity, it can hold a bank account per currency.
  • Reads are masked the same way for every entity: list them with GET /api/v2/storefront/billing/payees (list_payout_payees) and you get the last 4 characters of each account number, never the full value.
  • Removing a payee is a bank-detail change control and is handled by Interchange finance — contact support.

​
Interchange-cleared vs seller-cleared

A media buy is settled one of two ways: Interchange-cleared settlement requires payout details on file before Interchange can disburse what it clears — it has no way to pass a payment on without them. This does not block activation: a normal storefront can go live and start transacting first, accruing funds against every Interchange-cleared booking, and add payout details afterward. Missing payout details do not silently change a normal storefront booking to seller-cleared. Today, every normal storefront booking is Interchange-cleared. Storefronts will be able to choose seller-cleared settlement in a future release, but that option is not configurable yet and is not selected per booking. Existing official sales-adapter buys may be seller-cleared because those parties already settle under an external agreement. With seller-cleared settlement, Interchange does not deduct a seller-side media fee from the publisher’s invoice or payment. Any separate platform charge to the buyer is not a deduction from the seller’s invoice. The seller Media Buys page shows the resolved method on each booking as Interchange-cleared or Seller-cleared. A booking with no buyer-side record at all — for example one placed by a third-party AdCP buyer, which never has a local Scope3 record — resolves its settlement method from the storefront’s own current routing configuration, since that is what actually determines it (spec §12). Only a booking that predates the settlement-method record itself, and where a local buyer-side record positively shows no method was ever captured, shows Settlement method not recorded for this buy — the platform never overwrites what an existing legacy record shows with a later inference.
Interchange no longer uses Stripe for storefront payouts. If you set up billing through Stripe Connect before, enter your bank details once in Settings → Billing (or via set_payout_details) to keep Interchange-cleared settlement on your media buys — bank details held by Stripe cannot be migrated. Nothing else changes: fees, currency, and net terms carry over.

​
Organizations and accounts

An organization can manage billing for the accounts under it by passing ?targetCustomerId=<accountId> on billing endpoints; access is validated against the organization/account hierarchy. Accounts always inherit billing from their organization and cannot set up their own.

​
Billing activity

The Payout activity section at the top of the Payouts tab on the org Billing page shows payout runs as they happen — status, period, entity, currency, amount, and date — via Get payout activity. It’s empty until your first payout run; nothing is fabricated in the meantime.

​
Task reference

Set payout details

PUT /billing/payout-details — bank account for payouts

Get billing config

GET /billing — fees, currency, net days, masked payout details

Set payout payee

PUT /billing/payees — bank account per legal entity per currency

List payout payees

GET /billing/payees — masked payees on file

Update billing config

PUT /billing — fees, currency, net days (admin)

List billing accounts

GET /billing/accounts — billing status across your organization’s accounts

Get payout activity

GET /billing/payout-activity — payout activity as it happens