Core Concepts
Understand the core business objects in the API, including merchants, stores, terminals, sales, transactions, applications, installations, accounts, payouts, and webhooks.
Use these pages to understand the core business objects, payment resources, and integration resources you work with across the API.
Start with the core hierarchy
The merchant is the top-level business entity in the API. It contains business information and provides the main context for resources such as stores, accounts, applications, subscriptions, and reporting.
A store represents a merchant-owned sales channel or location. Use it to understand where sales happen and how payment activity, terminals, and optional webhooks can be scoped below the merchant level.
A terminal is a payment device used for in-person payments. Terminals belong to stores and are the operational resource for POS payment flows.
An account is the balance resource that holds funds before payout. It includes balances, holder information, payout settings, and the next payout date.
Understand the payment lifecycle
A sale is the primary payment object that represents the amount to collect. It carries the business context for a payment, including amount, customer, allowed payment methods, and related transactions.
A transaction is the payment operation performed within or for a sale. It captures execution details such as status, processor information, amount, settlement information, and terminal details.
Sale Lifetime shows how a sale changes over time as transactions are created, completed, cancelled, failed, refunded, or retried. Use it to understand sale status, transaction status, and the open, paid, refunded, and reversed amounts.
A customer stores the identity and contact details for a person or organization. You can associate customers with sales so you can reuse customer data and track purchases over time.
Metadata is a flat key-value object you can attach to supported resources such as customers and sales. Use it to store your own identifiers and business context without changing the core resource schema.
Understand integrations and eventing
An application is an integrator-facing resource with its own identity, scopes, type, and OAuth client credentials. It represents the reusable software client that accesses the API.
An installation links an application to a merchant context. It turns the application definition into an active integration instance with its own status, scopes, and optional event subscriptions.
A webhook sends event notifications to an external URL. Use it for event-driven integrations that react to changes in resources such as sales and transactions instead of polling for updates.
Understand settlement
How these concepts connect
- A Merchant is the top-level context for the business.
- A Store belongs to a merchant, and a Terminal belongs to a store.
- A Sale represents the business intent to collect money and can include a Customer and Metadata.
- A sale can produce one or more Transactions, and Sale Lifetime explains how sale amounts and statuses change as those transactions progress.
- An Application can be installed for a merchant through an Installation, and a Webhook can notify your systems when relevant events occur.
- An Account holds funds before settlement, and a Payout moves those funds to a bank account.
Read by use case
- If you're building checkout or POS flows, start with Merchant, Store, Terminal, Sale, Transaction, and Sale Lifetime.
- If you're syncing customer and order context, read Customer and Metadata.
- If you're building a partner integration, read Application, Installation, and Webhook.
- If you're reconciling balances and settlements, read Account and Payout.
Updated 10 days ago