CompanyGraph
A payment becomes merchant cash only after several institutions agree that the transaction can continue.
The merchant needs a completed sale
A shopper needs a purchase to work. A merchant needs the right amount to be authorized, captured when the order is fulfilled, settled through the payment system, paid out to the merchant account, and matched to the order in its ledger. Adyen supplies much of that sequence, but the merchant, issuer, network, bank, and shopper each control a different part.
Adyen's 2025 annual report describes a financial-technology platform combining payments, data-driven insights, and financial products through a single stack. The report describes the platform's scope, not a guarantee that every attempted payment becomes cash or that every merchant sees the same risk and payout terms.
Authorization reserves money; it does not transfer it
When the shopper submits a payment, Adyen validates the request, applies risk checks, and sends an authorization request to the relevant card network, issuer, bank, or other payment method. Adyen's lifecycle documentation defines authorization as approval after payment details and risk checks pass, with funds reserved. The payment lifecycle also says authorization remains valid only for a period.
An authorized payment therefore establishes a temporary permission and hold. It does not prove that the goods are in stock, that the merchant will ship them, or that the funds will ultimately settle. If the merchant waits too long, the authorization can expire. A payment that looks successful on the checkout screen can still be cancelled, refused later, or become a customer-service problem.
Capture ties the payment to fulfillment
Capture is the step that turns the reserved amount into a request for transfer. Adyen documents manual capture for orders where the merchant wants to wait until goods ship; the merchant can capture the full amount, a partial amount, or cancel the remainder. Adyen's capture guidance makes the physical relationship clear: the payment state can be held until the order condition is met.
This creates a boundary between commerce and finance. A warehouse scan may establish that a parcel was dispatched. A capture request establishes what amount the merchant asked to collect. Neither establishes that the shopper received the parcel or that a return will not occur. Partial shipments, split orders, subscriptions, and in-person sales each produce different capture and reconciliation work.
Settlement and payout are another path
After capture, the payment moves through the financial institution and settlement process. Adyen's documentation distinguishes statuses such as SentForSettle and Settled and says payout follows the merchant's sales-day schedule. Settlement status is evidence that the transfer progressed through a defined financial path; it is not the same as the merchant's internal order being closed.
Working capital makes the distinction practical. A merchant may ship before payout arrives, hold a reserve against chargebacks, or need funds in a currency different from the shopper's. A payout delay can force the merchant to slow fulfilment even while authorization and capture are functioning. A platform that processes volume does not remove the merchant's need for cash at the right time.
One platform still contains several institutions
Adyen's single stack can connect online and in-person transactions, risk data, reporting, and financial products. It cannot replace the issuer that decides whether a cardholder has funds, the network that routes a card transaction, the local payment method that sets its own rules, or the merchant that controls inventory and delivery.
That is why a unified integration is not the same as one physical condition. A merchant can see a common dashboard while separate banks, currencies, settlement calendars, terminals, and regulatory permissions sit underneath. The platform can reduce duplicated interfaces and make a transaction history more coherent; it cannot make those external conditions identical.
Risk decisions change which payments can proceed
Fraud checks and authentication are not a single yes-or-no property of a shopper. They combine payment details, device and account signals, merchant rules, network responses, and regulatory requirements. A refusal may protect the merchant and issuer while denying a legitimate purchase. An approval may still become a chargeback if the cardholder disputes the transaction or the merchant cannot show delivery.
Adyen's annual report describes Dynamic Identification and Adyen Uplift as tools that use transaction data to balance fraud, conversion, and customer experience. The report supports the role of data-driven decisions, not the claim that more data automatically improves every payment. The model remains dependent on useful labels, monitored error rates, privacy controls, and someone able to change a rule when the result is wrong.
Records describe payment states
A checkout response records what happened to an authorization request. A webhook can tell a merchant that a status changed. A capture record shows the amount requested. A settlement report shows which payments reached a later financial state. Adyen's reporting documentation maps these statuses to different reports. The reporting guide is valuable precisely because it does not collapse them into one "transaction complete" field.
The merchant's order ledger, warehouse record, bank statement, refund record, and customer complaint observe other boundaries. They can disagree without one system being meaningless. A settled payment can be refunded; a delivered order can be disputed; an authorization can be reversed before a shipment. Correction requires the identifiers and authority to connect the payment to the order, customer, bank, and rule that must change.
Money decides which response is available
Adyen and the merchant must fund fraud losses, reserves, customer support, refunds, reconciliation, security, and system availability before the next transaction produces revenue. A merchant with a narrow cash buffer may choose automatic capture to receive funds sooner, while another may delay capture until shipment to reduce refund and inventory risk. Neither choice is simply a feature preference; it changes who carries the financing and failure burden.
Payment pricing also changes access. A merchant may accept a higher fee for a payment method that converts more shoppers, or reject a method whose fraud and dispute costs exceed its margin. A dashboard can show the fee and status while omitting the working capital and customer-service work that made the sale feasible.
A payment platform is complete only when the states remain connected
Adyen's useful capability is the connection among payment request, risk decision, authorization, capture, settlement, payout, reporting, and correction. Its single stack can shorten the distance between those observations and make data available for the next decision. It cannot make a bank's reserve, a merchant's inventory, a customer's dispute, or a local rule disappear.
A completed payment account follows the money until the merchant can reconcile it to the fulfilled order and follows the feedback when the order is refunded, disputed, or misclassified. Processed volume is an important measurement, but it is not the same as merchant cash, customer value, or a correct outcome. Those remain separate achievements.