Platform Payments Glossary: 200 Terms for Marketplace Operators

200 platform payment terms and how to use them#

Authorization can reserve card funds; capture starts the next payment step; a payout sends an available amount to a destination account. Confusing those events produces bad cash forecasts and premature 'paid' messages. The 200 numbered entries below define payment terms and give an operator check for each, followed by guidance on ownership, system labels and verification.

These are plain-language definitions for orientation. Provider fields, accounting policies, contracts and applicable law can add specific meanings or requirements. Use the definition to ask a precise implementation question, then attach the source and example from your own stack when the answer affects money movement.

For example, a founder deciding whether to promise same-day seller payment needs the payout rail and usable balance, not just a successful card authorization. Product can display 'payment authorized' while finance tracks the uncaptured amount and engineering records its expiry. That shared record is more useful than renaming every stage 'success.'

The promise each entry should keep#

Each term should answer three things quickly:

• what it is
• where it appears in your flow
• what breaks if you get it wrong

Read the terms that your flow uses first#

Forty entries are marked 'Start' as a suggested first pass for a marketplace accepting cards and paying sellers. The other 160 are marked 'Scope': review them whenever your actual rail, country, billing model or risk program uses them. This is an editorial reading order, not a claim that only 40 terms can block launch.

It also has boundaries. Coverage depends on what is enabled in your stack and the programs or markets you operate in. Terms related to Open Banking, Virtual Accounts, or some tax workflows may be central in one implementation and irrelevant in another.

The operator checkpoint before release#

If your flow uses a term that is missing from the glossary, record a draft definition and ask the responsible domain owner to validate it against the relevant source. Escalate legal interpretation to counsel when necessary; ordinary API vocabulary does not need a legal approval queue.

The glossary: 200 terms by workflow#

Each numbered entry has a definition and an operator check. 'Start' marks 40 suggested first-pass terms; 'Scope' marks 160 further entries to review whenever your product uses them. The checks are practical suggestions. They do not change contract, regulatory, provider or accounting requirements.

1–20: Card acceptance#

PCI SSC payment terminology, Stripe authorization/capture guidance and CPMI terminology. Checks below are suggested operating actions, not universal provider rules.

21–40: Bank rails and transfers#

Nacha's ACH developer guide, RTP network information and FedNow overview. Bank support, rail rules and provider cutoffs determine your actual flow.

41–60: Accounts, cross-border payments and FX#

Swift's explanation of messaging and the FCA's AIS/PIS definitions. Account structures and conversion terms require the selected provider's contract.

61–80: Marketplace funds and obligations#

Stripe's marketplace refund/dispute guidance illustrates why charge, transfer, payout and liability must be distinguished. The definitions here describe concepts; they do not establish that your provider supplies escrow or safeguarding.

81–100: Compliance and risk review#

FATF's Recommendations and OFAC's Sanctions List Service provide primary context. Actual obligations follow the applicable regime and obliged entity. FinCEN's CDD framework is a U.S. covered-financial-institution example, not a mandate for every marketplace.

101–120: Authentication and payment-data security#

PCI SSC terminology and EMVCo's 3DS overview distinguish data protection from authentication. Check the current standard and your actual assessment scope.

121–140: APIs, events and reliable execution#

Stripe webhook guidance, idempotency documentation and the ISO 20022 framework. General engineering concepts below need a specific implementation contract.

141–160: Ledgers, cash and reconciliation#

These are basic accounting concepts, followed by suggested reconciliation checks. Stripe's balance report is a concrete provider example, not the authority for every entity's accounting policy.

161–180: Billing and operating metrics#

Metric definitions depend on the reported population and policy. Stripe Billing analytics demonstrates configurable definitions; document yours instead of assuming all dashboards calculate the same number.

181–200: Tax documents and reporting#

Use current IRS forms/instructions, the FinCEN FBAR guidance and EU DAC7 guidance. These entries explain terms, not universal filing or payout requirements.

How to use this glossary without slowing your launch#

Use the numbered tables as a reference while reviewing your payment flow. Pick one transaction or seller account and identify the terms its records actually use. Add provider-specific field names and statuses to your internal glossary rather than reading all 200 entries as a launch checklist.

Map terms to real workflow surfaces#

Group terms by workflow category instead of keeping one undifferentiated list. That makes them faster to find and easier to apply. For each launch-critical term, identify where it appears in practice: an onboarding step, an API field, a provider dashboard label, a finance export column, or a support queue status.

Treat disputed terms as decisions, not wordsmithing#

When a definition changes a response, document the decision. AVS compares billing-address data with issuer-held information; a mismatch is a fraud signal, not conclusive evidence of fraud. Risk should decide how that signal affects the relevant checkout, while product and support use wording that accurately describes the result.

Keep approved wording in a dedicated definitions or methodology appendix so teams know where the canonical version lives.

Record source context and escalation rules before go-live#

High-impact terms need more than a shared phrase. Keep a lightweight evidence pack for key terms that includes the approved definition, where it appears, and an example record.

A suggested 40-term first pass, with 160 further terms by scope#

A term is launch-critical when a current dependency needs it. A bank-only marketplace can prioritize ACH and its return handling over card capture; a regulated open-banking product may need AISP/PISP scope immediately. Promote any 'Scope' entry your actual flow depends on.

A practical triage rule#

Put a term into first-pass launch review when it can change a legal reading, a contract duty, or a go-live decision gate. Defer it when it mainly improves optimization or reporting and no current artifact depends on it.

A practical triage rule#

Prioritize a term when misunderstanding it can change a current amount, recipient, authorization, deadline or incident response. Terms that have no present dependency can wait, but tax, security and regulatory obligations do not become optional because a reading-order label says 'Scope.'

For each term, keep a small evidence pack with:

• approved internal wording
• controlling source context, statutory and contract where applicable
• one real artifact where the term is used, such as a field label, template, or contract clause

That keeps plain-language guidance usable while staying aligned to the definitions that control real decisions.

Payment flow terms that break launches when misunderstood#

A plain-language definition is the starting point. Keep the source, example field, owner and decision alongside it so the team can explain how it applies in this implementation.

Payment-flow labels are not interchangeable. Before go-live, lock Authorization, Capture, Chargeback, Acquirer, and Acquirer Processor to one approved internal wording, then map each one to the exact provider document, contract language, webhook or event name, and finance field your team actually uses.

Do not reuse a success label from one step as proof that every later step is complete. Keep each state label tied to its own event and report context, and document where that label is authoritative in your stack.

Keep state labels separate#

Keep payment-state language separate from nearby terms such as ACH, 3-D Secure (3DS), AVS, BIN, and PCI DSS. Once those categories get mixed into payment-state naming, triage gets noisy and ownership gets blurry.

For Acquirer and Acquirer Processor, keep one internal map that answers three practical questions:

• which counterparty owns the label
• which dashboard, report, or file shows it first
• who escalates when card acceptance fails

What to verify before go live#

Before launch, run one terminology check across the artifacts teams actually rely on:

• user-facing product copy after pay, fail, refund, and dispute outcomes
• webhook or event names engineering consumes
• finance report columns used for cash, fees, and exceptions
• the controlling provider or contract wording when meaning is disputed

If labels differ across those artifacts, keep the difference only when it is deliberate and documented.

Use the official source when wording affects legal interpretation#

If a term depends on a regulation, retain the applicable official text and effective-date context rather than relying on an article's citation alone. Record the interpretation your program actually follows and who reviewed it. A historical rule number does not establish that the same rule is in force for your current product.

Bank rails and account infrastructure terms that change settlement behavior#

Rail labels should map to real settlement evidence, not generic status text. Keep ACH, RTP, and SWIFT separate in your product, ops, and finance views so your team can tell users what actually happened.

A payment rail carries instructions and funds under its own participation and processing rules. Institutions can connect through operators, correspondent banks or service providers; both customer banks need not be direct members of one network. Record the route your provider uses and the evidence available for each stage.

Compare rails by grounded behavior and explicit unknowns#

Keep account primitives separate in implementation#

Use account identifiers for their actual purpose: ABA routing numbers identify U.S. bank routing, IBAN identifies an account in participating countries, and BIC identifies an institution or entity. BIN/IIN belongs to card issuing, not bank-account routing. Format validation does not prove that an account belongs to the intended payee.

Treat Virtual Accounts as a reconciliation test, not a promise#

A virtual account can help attribute incoming payments, but its legal/account structure depends on the provider. Follow one payment from the assigned identifier through the provider entry, invoice match and ledger posting. Verify account ownership, permitted use and protection of funds before describing it to customers as their bank account.

Risk and authentication terms that control approval and fraud exposure#

In card-not-present checkout, 3-D Secure (3DS) and Address Verification Service (AVS) are controls you tune, not badges you enable and forget. They can reduce fraud exposure, but they can also add checkout friction.

What each term is doing in a card-not-present flow#

A card-not-present transaction is one where the physical card is not shown and card data is sent remotely, for example online. In that context, a transaction can still become a chargeback after approval, so approval alone does not remove post-approval loss risk.

EMV 3DS supports authentication in online card payments. A frictionless flow can complete without an interactive challenge; a challenge flow asks for additional authentication, such as a one-time code or biometric confirmation. A successful result does not guarantee approval or remove every kind of dispute.

The ACS is the issuer-domain component involved in deciding or performing 3DS authentication. Use your provider's exposed result and reference fields to link authentication to the payment attempt. Do not infer bank settlement from an authentication success.

Approval, fraud, and friction move together#

Separate the effect of authentication from the effect of an interactive challenge. Review completion, abandonment, approval and later fraud outcomes for the relevant cohort before changing the configuration. A payment may use 3DS without adding a visible customer step.

When fraud pressure rises, review where losses are concentrated and tighten controls in those paths first. When approvals fall without clear fraud improvement, review your current 3DS and AVS configuration and checkout experience before adding more friction.

For any single transaction, support, ops, and finance should be able to see the same facts: whether 3DS was invoked, whether authentication was completed, what AVS returned, and whether a later chargeback occurred.

Incident checklist for triage#

• False declines: Sample recent declines, verify whether 3DS and AVS outcomes are present in gateway responses, and check for checkout abandonment around extra authentication steps.
• Account takeover signals: Look for patterns where legitimate users fail authentication or where billing details change in suspicious ways, then confirm which 3DS events your provider exposes.
• Post-authorization fraud review: Sample approved transactions that later became chargebacks and compare authorization records with available 3DS and AVS outcomes to find repeat patterns.

Compliance terms that trigger policy gates and onboarding delays#

Do not collapse compliance into a generic "passed compliance" badge. These states can gate onboarding and payouts, so they need to stay separate and evidence-backed.

KYC identifies and verifies customers; KYB describes checks on a business, its ownership and representatives. AML is the broader program of controls against money laundering and related financial crime, including due diligence, monitoring and case handling. The FATF Recommendations are international standards implemented through jurisdiction-specific measures, not a single universal platform policy.

Do not collapse KYC, KYB, and AML into one status#

Keep separate machine-readable states for KYC, KYB, and AML so a hold can be explained and resolved quickly. If your admin only shows "compliance pending," teams cannot tell what changed, who owns the next action, or what evidence is missing.

If payouts are compliance-gated, do not promise external timeline SLAs until those states are visible and consistent across ops, support, and finance surfaces.

Jurisdiction and program setup can change obligations#

Do not treat shorthand labels like 5th Anti-Money Laundering Directive (AML5) as self-executing policy. AML5 obligations, thresholds, and market applicability require official legal text and counsel-approved program interpretation.

If a policy restricts money movement, record the actual obligation, scoped restriction and authorized review process. A screening hit may need investigation; it is not automatically a confirmed sanctioned person. Keep the evidence needed to explain the decision without exposing confidential reporting details to unauthorized teams.

Map each gate term to retrievable evidence#

If a term can block money movement, map it to auditable artifacts your team can retrieve quickly.

Use named checkpoints, not vague compliance language#

Name the actual checkpoints in your program: identity verified, ownership reviewed, screening disposition recorded, monitoring case open or payout restriction imposed. Record the evidence, reviewer and next action for each.

Tax and reporting terms finance teams must map before first payout#

Separate platform payee-document and reporting obligations from a payee's personal tax return. W-9, appropriate W-8 forms, reportable 1099/1042-S payments and DAC7 may affect platform operations when their scope applies. FEIE, Schedule SE, FBAR and Form 8938 concern taxpayer-specific duties; they are not universal prerequisites for releasing a seller payout.

Treat tax terms as collection and reporting triggers#

These terms affect what your team may need to collect, retain, mask, export, and review before or after payout. They also affect onboarding copy, admin permissions, payout eligibility logic, and whether finance can produce a defensible record later.

Map each applicable tax term to the obligated party, tax year, required document, collection or filing event, protected storage and owner. Use current instructions for thresholds and exceptions. Missing documentation can require a withholding branch; it does not invariably authorize holding the full gross amount.

FEIE is the clearest example of why loose tax language causes trouble#

FEIE concerns qualifying individuals with foreign earned income, a foreign tax home and the required residence or physical-presence conditions. It does not mean 'no U.S. reporting' and does not reduce self-employment tax on excluded self-employment income. The claim uses Form 2555; it is a taxpayer filing matter rather than a standard platform onboarding document.

The physical-presence route generally requires 330 full days in foreign countries during 12 consecutive months, alongside the other eligibility conditions. Full-day and travel-day treatment needs the current IRS instructions. The IRS exclusion calculation guide lists maximum amounts of USD 130,000 for 2025 and USD 132,900 for 2026; partial-year qualification adjusts the limit. Those caps do not determine a platform's payout eligibility.

Retain service periods, payment dates and payee-document versions for the reporting your platform actually owes. They can also help the payee explain income timing: cash-basis reporting and the exclusion's earned-year allocation are different questions. Do not tell payees that residence abroad removes reporting duties or treat their personal FEIE claim as a withholding exemption.

Product and finance handoff checklist#

Before first payout, agree on this for each tax-related term your program uses:

• which tax profile fields or documents are collected in product versus reviewed offline
• which values are required before payout versus allowed to remain pending
• which values are masked in support and ops tools, and who can unmask or edit them
• which records finance can export, including status, timestamps, version history, and linked payout account
• which tax terms appear in user-facing copy, help content, and payout hold reasons

Run a live verification pass with sample accounts before launch. Finance should be able to retrieve tax status, linked form or document records, who changed them, when they changed, and whether payout was released or held without engineering intervention.

Confirm actual collection, withholding and reporting duties by program, jurisdiction, payee status, income source and tax year. Foreign-payee forms are a family with different purposes, not an interchangeable 'W-8 passed' state. Restrict personal tax data to authorized users and avoid collecting a payee's unrelated personal-return documents without a justified purpose.

Data and messaging standards your engineers need early#

Treat engineering terms as controlled definitions before implementation. If ISO 20022, ACH, RTP, or Open Banking appears in a spec, pin it to a controlling source, document version, and owner before your team finalizes internal labels.

A standard defines message structure or semantics; your provider's implementation guide defines which version, fields and behaviors it supports. ISO 20022 is a financial-message standardization framework, not a payment rail or a promise that differently implemented messages will interoperate automatically.

Keep a compact evidence pack for each external messaging dependency:

• controlling source and owner
• whether the full source is actually accessible to your team
• document version and date
• internal plain-language definition approved for product, engineering, and finance
• change-approval path when wording changes

For a message dependency, record the schema/version, required fields, code lists and provider's supported interpretation. If the full document is inaccessible, ask for the requirements needed to implement the flow. Document metadata alone cannot establish the behavior of a payment API.

Use a real event example in the glossary record. A Stripe webhook can be retried or delivered out of order; verify its signature, retain a durable event record and avoid repeating side effects. Its documentation and your handler's contract are relevant evidence. An unrelated vendor's certification checkpoint is not proof of your event semantics.

Who owns each term inside your team#

Assign an owner for each high-impact term before go-live, and record that ownership in writing. The goal is practical: one person can answer what the term means in your product, which source controls it, and who decides when that meaning changes.

A lightweight ownership pattern usually works best:

• one primary owner for the internal definition
• one approving partner for edge cases
• one escalation path for changes that affect eligibility, reporting, or money movement

A public glossary gives orientation; your internal record explains actual usage. An accounting definition may depend on policy, an API status on the provider version, and a regulatory term on applicable law. Keep those authorities distinct and resolve conflicts through the relevant domain owner.

A practical ownership matrix#

Use this as an internal assignment model, not a universal rule:

Shared ownership needs a named decider#

Some terms cross team boundaries and need explicit decision rights. Chargeback often spans ops, finance, product, and sometimes compliance. KYB plus risk review often spans compliance, ops, and product.

For shared terms, define:

1. the primary decider for definition changes
2. the approver for customer-facing wording
3. the owner of the evidence pack and audit trail

Without that, split-brain terminology is common. Different teams end up using different labels for states that carry different operational consequences.

Keep terms aligned with real system behavior#

Review definitions when a provider version, policy or reporting method changes, and consider a recurring review for critical terms. Check three surfaces: user-facing language, provider/internal events and finance/compliance exports. Monthly can be a useful internal cadence; it is not an industry requirement.

For a changed term, retain the prior definition and effective date alongside the new wording. Confirm whether existing reports or customer promises need correction. A document version or publication date identifies a source; it does not by itself prove that your implementation follows it.

The glossary only helps if each term still matches how your product, code, operations, and reporting actually behave.

Red flag term confusion and the fixes to apply this week#

If a term drives money movement, compliance state, or incident routing, treat this week as a terminology-control sprint. Give it one dated internal definition and one owner.

For example, KYC verified can coexist with an AML investigation or a separate restriction. Show the actionable reason and owner to authorized operators; expose only appropriate information in customer messaging.

Build your glossary evidence pack before go live#

Before go-live, make the glossary operational. Each high-impact term should have an owner, a source of truth, a traceable system reference, and a clear conflict rule when definitions differ.

Document precedence explicitly in your glossary. If documents conflict, state the hierarchy your team follows. For example, contract materials may define an order of precedence, and applicable statute, rule, or regulation can control when in conflict.

Validate terms with a sampled transaction trace, not a meeting. Follow a sample from request to provider reference to internal record to reconciliation export, and confirm that the labels stay consistent end to end.

In an illustrative card flow, USD 100 authorized and USD 80 captured leaves USD 20 uncaptured; the released balance depends on the payment method and provider's rules. If the provider deducts a hypothetical USD 3 fee from the captured amount, USD 77 may become available before a later payout. None of those events proves bank receipt or removes later refund/dispute risk. Record the actual amounts and outcomes rather than copying this example's fee into your pricing model.

Require explicit sign-off for the clusters where language errors are expensive: card flow, compliance gating, payout operations, and tax-document readiness. Treat any term with no linked source, no source field, or no retrieval path as unresolved.

For adjacent build decisions, pair this pack with The Complete Guide to Platform Payments: Everything a Marketplace Operator Needs to Know, State of Platform Payments: Benchmark Report for B2B Marketplace Operators, and Platform-to-Platform Payments: How to Build B2B Settlement Between Two Marketplace Operators.

The takeaway for marketplace operators#

A useful definition helps someone take the next correct action. Product should label an authorization accurately, finance should distinguish seller liabilities from platform revenue, and ops should recover an unknown payout before initiating a replacement. The glossary should make those choices easier.

Treat terms as operating controls#

Separate a general definition from an unresolved implementation question. You can explain what a webhook is while marking your provider's delivery guarantees as unverified. Resolve the actual dependency before making a production promise, rather than leaving every ordinary term undefined.

Launch critical first#

Prioritize terms that affect live outcomes now, then stage the rest. A simple sequence is:

• assign immediate ownership and a go-live check to terms that can block or permit activity
• queue terms used mainly for optimization, reporting, or later expansion
• keep any term with no source, owner, or retrieval path out of policy commitments and external promises

For a new market or product, review which terms now have a live dependency: a new rail can introduce mandate/return rules, and a new seller jurisdiction can introduce reporting duties. Update owners and evidence at the same time.

Verify terms against real flow evidence#

Keep the source version and the original relevant document where it supports a material decision. Confirm current applicability rather than assuming that a historical paper, source-conversion warning or rule citation controls your payment flow.

The main failure mode#

The practical failure is a label that drives the wrong action: paying twice after a timeout, counting authorized funds as cash, or treating identity verification as every compliance approval. Find that mismatch in a transaction trace, correct the definition and update the affected workflow.