> ## 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.
# Billing
> Organization IU plan options, payout bank details, and how Interchange pays your storefront
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](/v2/buyer/billing/plan-and-billing)**,
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:
```
https://api.interchange.io/api/v2/storefront
```
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](/v2/buyer/billing/organization-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:
| Plan | Monthly commitment | Included IUs | Overage |
| ------------- | -----------------: | -----------: | ------: |
| Pay as you go | \$0 | 0 | \$5/IU |
| 250 | \$1,000 | 250 | \$5/IU |
| 1,000 | \$3,000 | 1,000 | \$5/IU |
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 will fund buyer activity. The current coarse-denomination
planning value for an activated social account is 4 IUs per account-month,
including mirror, read, write, routine sync, and up to 13 months of history.
The final denomination and count are not set, and that meter is currently
non-billing; see the
[Organization IU Rate Card](/v2/buyer/billing/organization-iu-rate-card) for
the availability boundary.
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.
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](/v2/storefront/tasks/get-readiness) 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 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:
| Settlement | Who invoices the buyer | Available today |
| --------------------------------- | --------------------------------------------------- | -------------------------------------------- |
| **Interchange-cleared** (`agent`) | Interchange invoices the buyer and pays you | All normal storefronts |
| **Seller-cleared** (`operator`) | You invoice the buyer under your existing agreement | Existing official sales-adapter arrangements |
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=` 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](/v2/storefront/billing/tasks/get-payout-activity). It's
empty until your first payout run; nothing is fabricated in the meantime.
## Task reference
`PUT /billing/payout-details` — bank account for payouts
`GET /billing` — fees, currency, net days, masked payout details
`PUT /billing/payees` — bank account per legal entity per currency
`GET /billing/payees` — masked payees on file
`PUT /billing` — fees, currency, net days (admin)
`GET /billing/accounts` — billing status across your organization's accounts
`GET /billing/payout-activity` — payout activity as it happens