Skip to main content
Deprecated. This page documents the v2 storefront API, which is being retired for external callers. Use Plan and billing in V3 instead.
Billing determines how money reaches you when your Seller Account uses consolidated billing, where Apostra bills the buyer for you and passes on each payment once it arrives. An administrator enters the 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 Apostra pays you by bank transfer, net of the platform fee and any additional fees on your billing config. A standalone Seller Account administrator can enter these details directly. For a child Seller Account, an administrator of its parent billing organization enters them; a child-only administrator can see that billing is organization-managed but must ask a parent-organization administrator to manage billing and payout details.

​
When your organization manages billing

A Seller Account that belongs to an organization doesn’t hold its own billing: the organization holds the contract, the plan and the payout authority for every account under it. Billing and payout changes made from inside the Seller Account are refused, and the refusal names the organization, for example:
Payouts for Azerion are managed by the Azerion Admin organization. Switch to Azerion Admin to manage them.
  • If you administer the organization, open Settings → Organization → Plan & billing → Payouts in the Seller Account and choose Open Azerion Admin billing. That switches into the organization’s Plan & Billing, where the organization’s Payouts tab lets you manage each Seller Account’s payout details.
  • If you don’t, the refusal says that only an administrator of the organization can view or change billing. Ask one of them; there is no way to change it from the Seller Account.
The refusal is 403 ACCESS_DENIED. Its details tell an integration where to go next:
  • reason: billing_managed_by_organization.
  • billingOrganization: { customerId, name } of the organization that manages billing.
  • canSwitch: true when the caller administers that organization.
  • nextAction: switch_account when canSwitch is true, otherwise ask_organization_admin.
  • switchTo: { accountId } to pass to switch_account. Present only when canSwitch is true.
Setup is optional only for official Apostra sales-adapter Seller Accounts, where the downstream platform relationship already has an external settlement agreement. A third-party sales agent or a finished-product source with Listing is still a normal Seller Account and does not change settlement. A normal Seller Account uses consolidated billing, so payout details are required — but only to get paid. The billing_setup readiness check is advisory, not a go-live blocker: a Seller Account 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. A parent-organization administrator can 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 legacy v2 storefront base URL for Seller Accounts:
Authenticate every request with Authorization: Bearer $SCOPE3_API_KEY.

​
Organization IU plan and Rate Card

Plan & Billing → Plan & pricing is the Seller Account view of your organization’s one Effective IU Rate Card. Buyer activity, Seller Account work, Apostra, and every other IU-rated workload use the same plan, corporate pricing adjustment, rollover policy, and wallet. Your Seller Account 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. A Seller Account that uses another company’s agent does not purchase that company’s operate-agents-for-clients entitlement. The agent operator purchases the right for its own Partner organization, while each client billing organization keeps its own IU plan and each Seller Account keeps its own media-settlement terms. See Partner Program and agent operations for the operator, client-authorization, and certification boundaries.
The standard Organization IU Rate Card is published and effective in production. Every eligible organization can review and accept an applicable public plan, including its setup-credit terms when the Rate Card carries a setup credit. After you accept, Plan & Billing may show the accepted included-IU allocation, observed usage, and a display-only forecast. Accepting a paid plan starts billing under its terms; every organization with an accepted paid plan is charged. Existing accepted media-pricing arrangements are unchanged.
Without Distribution, a Seller Account keeps Listing connected to its third-party sales agent. Listing has no monthly commitment. Saving, enabling, and evaluating AI Business Rules is not an IU-rated activity. Listing also waives brief responses and qualifying media buys. Enhanced Reporting is recorded at 4 IUs per enabled connected account per billing period; Listing’s IU price is $0, so no money is charged. Listing + Distribution is available only when an approved Rate Card publishes it, and the exact proposal terms appear in Plan & Billing before acceptance. The standard Merchandising strategy is pay as you go at $5/IU, €4.50/IU or £4/IU, with no monthly IU commitment or included bundle. Distribution is priced separately through an accepted offer. The plan catalog below lists each plan’s price in every currency. The plans you can accept are the ones the effective Rate Card publishes for your organization, which Plan & Billing shows before acceptance. Prices are set per currency rather than converted, so a EUR or GBP price is its own published number and not the USD figure at an exchange rate. A corporate discount, a negotiated package, or a customized Offer replaces the list entirely. The current Rate Card activity schedule has exactly three published activities; see the Organization IU Rate Card. Pay-as-you-go usage is billed after each monthly period, and a pay-as-you-go plan has no included monthly IU allocation to roll over. A negotiated package can carry a monthly commitment, billed at the start of each period, and included IUs that roll over as the Rate Card page explains; 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 Seller Account-only discount.

​
Before your storefront runs briefs

A completed brief response is an IU-rated activity: your accepted Rate Card prices it, and the charge comes from that card, not from this page. Read the exact terms in the Organization IU Rate Card or from GET /api/v2/billing/iu-rate-card/v4. A plan that waives brief responses charges nothing for them and asks for nothing extra. A brief from a buyer’s sandbox account (AdCP sandbox: true) is a test, not demand, and is never charged, whatever your plan. Your storefront still answers it in full, and the prerequisites below still apply to it. When your accepted plan does charge for brief responses, your storefront must meet two prerequisites before it runs one:
  1. Brief acceptance rules are active. The storefront that handles the brief has an active version of AI Business Rules, the Brief Acceptance policy, as set up under reviewing buyer transactions. Saving and evaluating the rules is free.
  2. Payment is covered. Your organization has a payment method on file or approved credit, or your plan carries a monthly commitment. A pay-as-you-go plan has no commitment, so it needs the payment method or credit.
Until both hold, a brief is refused before any work starts. The refusal is an INVALID_REQUEST with details.reason seller_prerequisites_missing, a details.missing list (brief_acceptance_rules, payment_authority, or storefront_unmatched when the brief’s storefront is not the Seller’s) and a typed next step for each. The buyer sees only that the Seller has not finished setting up. A Seller administrator fixes it in AI Business Rules, in Plan & Billing, or both, and the next brief runs. Apostra turns this refusal on per Seller; until it is on for yours, each check is counted and the brief runs.

​
Agentic Media Company plan catalog

This is the canonical customer-readable description of the current standard Agentic Media Company defaults used to author new Rate Card offers. These defaults are not available for production purchase until an approved Rate Card publishes them. Plan & Billing shows the exact currency price, access, payment terms, and effective dates before acceptance. An existing accepted plan keeps its snapshotted terms until its documented successor flow takes effect.
A seller first chooses who operates its sales agent. Listing Only and Listing + Distribution keep a seller-owned or third-party Sales Agent in control. Merchandising and Merchandising + Distribution use Apostra’s hosted Merchandising Agent. “Pay as you go” describes Merchandising’s usage price; it is not a separate plan name. Standard Merchandising excludes public distribution, self-serve Advertiser management, and Custom modular sources. The two standard Distribution plans exclude Custom modular sources and the customer-branded ChatGPT app. Enterprise includes only the Custom options written into the accepted offer. External AdCP buyers may buy on any commercially ready Seller storefront. The Seller’s terms, payment authority, rate card, and approval checks decide commercial readiness. Distribution gates public discovery only; it does not grant or withhold campaign-buying eligibility. Listing Only and Merchandising use standard support. Distribution pricing is available upon request and is issued through a versioned proposal. The accepted offer controls its monthly fee and IU rate, as well as its initial term, renewal, support, payment terms, and effective dates. IU usage is billed at period end. Standard plans have no included IU allocation or rollover. Prices are set independently per currency rather than converted at an exchange rate. A plan’s public or private label controls only where the plan can be selected; it does not determine whether the plan renews. The renewal cadence and notice period shown in Plan & Billing and in your accepted offer are the terms that apply. A private plan can renew automatically when those terms say it does, and a public plan can be configured not to renew automatically. Existing sellers can accept a Distribution upgrade with no monthly fee for its first 60 days. The 60-day period begins on the service-start date in the accepted offer. The IU rate stated in that accepted offer applies during the 60-day period. Continuing Distribution after the 60-day period requires accepting paid Distribution terms; Plan & Billing shows the exact IU rate, start date, end date, and successor terms before acceptance. Saving, enabling, and evaluating AI Business Rules is not an IU-rated activity. The current Rate Card activity schedule has exactly three published activities; see the Organization IU Rate Card. Your accepted Rate Card, not these offer defaults, is the authority for charges. The three Rate Card defaults are 1 IU for a completed Apostra merchandising cycle, 4 IUs for Enhanced Reporting per exact connected account and billing period after the control is enabled and a reporting subscription syncs successfully, and 1 IU for a qualifying Apostra media buy per billing period. For a seller, that is a non-social buy with positive impressions or spend; the buyer is charged for its own side of the buy separately. The selected plan then applies its activity terms. Listing paths waive brief responses and qualifying media buys. Merchandising paths—the Storefront agent plans—keep the catalog defaults for all three activities, including 4 IUs for Enhanced Reporting. Your accepted Rate Card is the authority for the final activity terms and IU price. Accepting a paid plan starts billing under those terms. See the Organization IU Rate Card. A seller’s media-buy qualification follows the latest authoritative delivery totals for the original billing period. A correction that leaves both impressions and spend at zero removes a provisional IU before invoicing; after invoicing, it goes through the normal auditable one-IU credit or reversal process against that original period. Later positive evidence may reinstate the same unit once, never add a second unit for the same buy and period. When the effective Rate Card carries a setup credit, a billing organization receives one automatic credit on its first IU acceptance, in the amount the Rate Card states. The current plans carry no setup credit. A Rate Card that carries no setup credit grants none, and an organization that already holds a credit keeps it until it expires. Existing customers qualify too. The credit is valid for exactly the number of elapsed days the Rate Card states from the acceptance commit, never a number of billing cycles, and any IU-priced activity in the organization’s shared wallet can use it. Seller Account provisioning may finish asynchronously without moving that expiry window, and later acceptances or Seller Accounts do not create additional credits. 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 credit or change the setup credit’s value or expiration. A code works on a Rate Card that carries no setup credit as well: it applies its adjustment and attribution, grants no IUs, and counts toward its redemption limit like any other redemption. The adjusted Effective Rate Card is shown before acceptance. Apostra issues these codes; Seller Account operators 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 plan record, including its Rate Card version, list and effective prices, discount, acceptance source, and term. The same history appears from buyer and Seller Account entry points.

​
Accepting a private offer for the next term

If Apostra 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 Seller Account 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. Apostra operators can inspect the same history, but cannot bypass the governing agreement’s cutoff or rewrite an accepted term. Apostra 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 Apostra 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 — Apostra does not accept on your behalf. Until then the Seller Account 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 Seller Account IU activity use the resulting same accepted plan; existing accepted media pricing stays separate and is not changed by the IU plan. For Free Seller Accounts included in the Rate Card pilot, a published offer can prompt a review from any Apostra app page. The Terms of Service step comes first. Review plans opens the existing plan review; an administrator must still choose a plan and explicitly confirm acceptance. Other members see Ask your admin, without the commercial terms. Not now returns to your work and allows the prompt to appear in a later app session. 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 in a later app session. 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

Apostra 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 Apostra 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: Apostra pays you after it receives the buyer’s corresponding payment, subject to the applicable payment terms. Each payout account holds one currency: for Seller Accounts on consolidated billing, your payout currency must match your Seller Account’s settlement currency (defaultCurrency). The settlement_currency_match readiness check blocks go-live on a mismatch.

​
Why Apostra needs your bank details

Bank details are how Apostra 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.
Apostra 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 Plan & Billing → Payouts — 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

A child Seller Account uses its organization’s payout destination until a parent organization admin creates a Seller Account-specific destination. In Plan & Billing → Payouts, select the direct child Seller Account; through REST, pass ?targetCustomerId=<child-id>. Child-only admins cannot create or change payout destinations. 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 Plan & Billing → Payouts 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 Apostra finance — contact support.

​
Consolidated billing vs direct billing

A media buy is billed one of two ways: You carry the buyer’s credit risk either way. Under consolidated billing Apostra acts as your billing agent: it puts your charges on the buyer’s consolidated media bill, collects, and pays you once the buyer’s payment arrives. Apostra takes no credit risk on your media, does not pay you before the buyer pays, and is not liable if the buyer does not pay. Accepting a buy means accepting the buyer’s credit risk, exactly as if you had invoiced the buyer directly. Consolidated billing requires payout details on file before Apostra can disburse a payment it has collected for you — it has no way to pass a payment on without them. This does not block activation: a normal Seller Account can go live and start transacting first, accruing funds against every consolidated-billing booking, and add payout details afterward. Missing payout details do not silently change a normal Seller Account booking to direct billing. Today, every normal Seller Account booking uses consolidated billing. Seller Accounts will be able to choose direct billing in a future release, but that option is not configurable yet and is not selected per booking. Existing official sales-adapter buys may be direct-billed because those parties already settle under an external agreement. With direct billing, Apostra 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 billing method on each booking. A booking with no buyer-side record at all — for example one placed by a third-party AdCP buyer, which never has a local Apostra record — resolves its settlement method from the Seller Account’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.
Apostra no longer uses Stripe for Seller Account payouts. If you set up billing through Stripe Connect before, an administrator of your billing organization must enter the bank details once in Plan & Billing → Payouts (or via set_payout_details) before Apostra can disburse accrued funds — bank details held by Stripe cannot be migrated. Nothing else changes: fees, currency, and net terms carry over.

​
Organizations and accounts

A parent organization admin can manage a direct child Seller Account by passing ?targetCustomerId=<accountId> on billing endpoints; every request validates the organization/account relationship. Requests authenticated only for a child account cannot create or change payout destinations. A child inherits its organization’s payout destination until a parent admin creates a child-specific override.

​
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