The order looked complete. The customer had paid, the warehouse had allocated stock and the shipping label was ready. Then one item slipped to a later shipment. A customs document sat unsigned. What looked like a normal order became a payment risk hiding between operations and finance.
That is where many payment integrations fail. Not at checkout, where most teams focus, but after it, when payment status has to move through an order-management system, warehouse workflow, marketplace balance, refund process and finance ledger. Along the way, small assumptions become expensive: paid means settled; authorized means safe to ship; retried means harmless.
The providers themselves document the complexity. Stripe notes that online card authorizations are generally valid for seven days. Adyen warns that late captures can increase the risk of failed capture, higher interchange, scheme fees and authorization-related chargebacks. Checkout.com research, underpinned by Oxford Economics, estimated that merchants in the United States, Britain, France and Germany lost more than $50.7 billion to false declines in 2022.
For retailers, 3PLs, freight platforms, marketplaces and B2B distributors, the issue is rarely one broken payment. It is the gap between payment state and operational reality. A card may be authorized while the order waits for stock. A bank debit may still be pending while a shipment is released. A refund may move through the wrong balance account.
1. Authorization expires before fulfillment catches up
The first edge case is time. Card networks do not know that a shipment is delayed because a supplier missed a dock slot or a warehouse split an order across two locations. They only know whether the authorization is still valid when the capture arrives.
For companies that capture when goods ship, this matters. A standard authorization window may work for simple retail orders, but it is fragile for long lead times, back orders, customs holds and built-to-order products. When the capture attempt comes too late, the business may face a failed capture, a higher cost transaction or a dispute tied to authorization timing. The operational lesson is simple: order aging and authorization aging are not the same thing. They need to be tracked separately. 
2. A timeout becomes a duplicate charge
The second edge case begins with uncertainty. A payment request is sent, the network connection breaks and the application does not know whether the processor completed the action. Someone or something retries the request. Without idempotency, that retry can become a second charge.
Stripe and Adyen both treat idempotency as a core protection against this problem. The business impact is broader than an awkward support ticket. Duplicate processing can create refund work, dispute exposure, reconciliation noise and operational distrust. In a high-volume environment, even rare duplicate events can consume finance and support time that should never have been spent.
3. Webhooks arrive out of order
Modern payment systems are event-driven, but events do not always arrive in the order a team expects. Stripe states that webhook delivery order is not guaranteed. It also warns that companies should not rely on a checkout success page to trigger fulfillment because a customer can complete payment and lose connectivity before the browser loads the page.
This is where a clean checkout flow can betray operations. If an order-management system marks an order as paid from a redirect alone, it may release goods before the server has a reliable payment event. If the system cannot handle duplicate or delayed webhooks, it may run the same downstream action twice. For logistics and e-commerce teams, the webhook is the control point between money and movement. 
4. Delayed payment methods are treated like cards
The fourth edge case appears when a business adds ACH, bank debits or other delayed-notification methods but keeps the same fulfillment logic it used for cards. Stripe documentation notes that some payment methods can have a two- to 14-day delay in payment confirmation. ACH direct debits can take up to four business days for notice of success or failure, with the payment remaining in a processing state during that period.
For a company shipping physical goods, that can become an unsecured extension of credit. A warehouse may see a paid order while finance still sees a pending payment. Unless the workflow distinguishes pending, succeeded and failed states, the business can ship inventory before the funds are actually safe. 
5. Currency and minor-unit errors distort the transaction
The fifth edge case looks small in testing and expensive in production. Payment APIs often expect amounts in the smallest currency unit. Stripe documents currency handling and settlement conversion. Adyen notes that some currencies, including CLP, CVE, IDR and ISK, may have provider-specific minor unit handling that differs from ISO expectations. It also documents amount-mismatch errors in wallet flows when front-end and back-end amounts do not align.
In cross-border commerce, a decimal mistake is not just a data-entry error. It can become an undercharge, an overcharge, a failed authorization or a reconciliation break. The risk increases when e commerce pricing, ERP invoices, marketplace commissions and provider amounts are calculated by different systems. 
6. One order becomes several captures
The sixth edge case appears when a single order becomes several shipments. Adyen notes that each separate shipment can correspond to a partial capture. It also warns that if the capture amount differs from the original authorization amount, split instructions may be needed or funds can be booked to the liable balance account.
This is common in omnichannel retail and distributed fulfillment. One item ships from a warehouse, another from a store and a third is delayed. Technically, the payment may still be captured. Operationally, the business now has a mapping problem: which shipment corresponds to which capture, which amount remains open, which seller or balance account should receive the funds, and what happens if one item is later refunded. 
7. Marketplace refunds hit the wrong balance
The seventh edge case matters most to platforms, marketplaces and freight businesses that collect money on behalf of third parties. Stripe documents that, in separate charges and transfers, the platform balance can be debited for fees, refunds and chargebacks. In destination-charge flows, the connected account may keep funds unless the platform reverses the transfer. Adyen’s marketplace documentation makes a similar point: missing or invalid split instructions can push the full transaction and fees to the marketplace’s liable balance account.
The customer sees one refund. The platform sees seller funds, platform commission, payment fees, FX differences and possible chargeback liability. If the refund logic does not mirror the original split logic, the platform can absorb losses that should have been allocated elsewhere. 
8. The business captures before it can truly ship
The eighth edge case is not only technical. The Federal Trade Commission’s Mail, Internet, or Telephone Order Merchandise Rule requires sellers to have a reasonable basis for shipping within the advertised time frame, or within 30 days if no time is stated. If they cannot ship on time, they must obtain the buyer’s consent to the delay or refund payment for unshipped merchandise.
Card networks also classify product-not-received disputes, including Visa reason code 13.1. That means a fulfillment failure can quickly become a payment dispute. For an operations manager, the key question is not simply whether the payment was captured. It is whether the business had enough confidence to fulfill what it had charged for. 
9. Soft declines are handled as ordinary failures
The ninth edge case is the soft decline that is really an authentication request. Adyen explains that an AUTHENTICATION_REQUIRED response means the issuer requires strong customer authentication and treats the refusal as a soft decline. Its 3-D Secure guidance warns that skipping 3DS when SCA is required can lower authorization rates or lead to declines. Stripe similarly notes that soft declines can trigger authentication flows and that retrying without handling authentication can lead to another decline.
The operational mistake is to treat these events as generic issuer failures. A blind retry does not solve an authentication requirement. It can reduce conversion, frustrate customers and produce misleading decline data. The right workflow routes the customer back into authentication, then records the reason clearly enough for finance and support to
understand what happened. 
10. The payment clears at the wrong economics
The tenth edge case is quieter because nothing visibly fails. The payment clears, but it clears at a worse cost. Cybersource documentation states that Level II and Level III processing for B2B customers can provide lower interchange rates in exchange for more transaction detail, especially for business, corporate and procurement cards.
For distributors, manufacturers, logistics providers and procurement-heavy businesses, this matters. Missing tax data, customer references or line-item detail may not stop checkout. It may simply make each large-ticket commercial-card transaction more expensive than it needed to be. The loss appears not as an error message, but as a margin pattern.
What disciplined teams do differently
The practical lesson is that payment integrations need to be treated as operational control systems, not checkout code. Strong teams build around several rules: use idempotency for write requests; assume network interruptions leave request outcomes uncertain until a webhook or object lookup proves otherwise; keep delayed-notification methods pending until success is confirmed; track authorization aging separately from order aging; and test captures, refunds and chargebacks against the same split logic used in production.
There is also a prevention layer around stored credentials and retry behavior. Adyen notes that network tokens can remain valid when a card expires or is replaced, and that account updater helps prevent declines from outdated cards. Visa similarly positions network tokenization and account-updater services as ways to keep stored credentials current and improve authorization performance. But retry discipline matters too. Adyen maps Visa integrity-fee categories related to excessive retries, while Stripe warns that card networks limit reattempts and recommends no more than eight retries for charges that allow them.
The broader point is not that digital payments are unreliable. It is that authorization, settlement, fulfillment, refund and liability are separate states, often owned by separate teams. Payment providers document those states in detail. Businesses lose money when internal systems collapse them into one.
The companies that protect margin best are not the ones that simply add more payment methods. They are the ones that connect payment logic to fulfillment, finance and operations with enough discipline that every team can see the same truth at the same time. For companies running payments across ERP, CRM, TMS, marketplaces and warehouse systems, the question is no longer whether payments are integrated. It is whether the integration reflects how the business actually operates.