Proof of Fulfilment Requirements

Proof of Fulfilment for PSP Onboarding: What It Is and Why Underwriters Ask for It A parcel reaching a customer's front door is fulfilment. But what is fulfilment when the customer bought software? What about a hotel room reserved six months in advance? An online course? A consulting engagement? The answer is important because proof of fulfilment requirements are not fundamentally about shipping documents. They are about demonstrating that a merchant completes the obligation created when it accepts a customer's payment. For a physical-goods merchant, that evidence might include carrier delivery records. For software, it might be an activation, download, login, or usage record. For a professional service, it might be a completed work order or evidence that the agreed deliverable was provided. For travel, the relevant event may be the stay, flight, rental, tour, or other service actually taking place—not merely the booking being created. That distinction explains why a payment service provider (PSP), acquirer, bank, or underwriting team may ask a merchant for fulfilment evidence before or during a payment-processing relationship. The underlying question is: After taking the customer's money, can the merchant demonstrate that it delivers what was promised?

The exact evidence requested varies by provider, acquiring arrangement, merchant model, geography, payment method, transaction profile, and individual underwriting assessment. Current PSP documentation itself illustrates this variability: Checkout.com, for example, explicitly states that onboarding information and document requirements differ according to factors including the country in which the business is registered. What does proof of fulfilment mean in payment underwriting? In merchant onboarding, proof of fulfilment is evidence that connects a customer transaction with delivery or completion of the product or service purchased. The word "delivery" should therefore be interpreted operationally rather than literally. The merchant should first answer: At what exact point have we completed our obligation to this customer? Only then should it ask: What record proves that happened? This produces very different answers across business models. Business model Possible fulfilment point Examples of evidence that may help demonstrate it Physical ecommerce Customer receives merchandise Carrier delivery record, delivery confirmation, collection record, warehouse-to-carrier records Downloadable software Customer receives or downloads the licensed product Download record, activation record, account event, timestamped server log SaaS Contracted access or service becomes available and is used as applicable Account provisioning, login records, subscription records, usage logs Online course

Promised course access or instruction is delivered Enrollment record, access logs, module activity, attendance or completion records where relevant Professional service Agreed service or milestone is performed Work order, completion record, signed acceptance, deliverable record, customer communication Hotel Accommodation service occurs Stay or check-in/check-out records, folio or other service records Passenger travel Transportation takes place Ticket-use records, boarding records, related travel-service evidence Event or reservation Customer receives the contracted event or reserved service Attendance, redemption, check-in, service-completion or related records These are examples, not a universal PSP checklist. Current card-network and PSP dispute guidance demonstrates the same business-model distinction. Stripe's documentation differentiates physical products, digital products or services, and offline services: physical-goods evidence often focuses on possession or delivery, while digital evidence can focus on login, download, or usage and service evidence can focus on documentation that the service was actually provided. That guidance concerns dispute evidence rather than a universal onboarding standard. However, it illustrates an important operational principle for merchants preparing for underwriting: the useful evidence changes with the obligation being fulfilled. Why might a PSP or underwriter care about fulfilment?

Payment underwriting is broader than establishing that a merchant is a real legal entity. Corporate verification can help answer: Does this company exist? Fulfilment evidence can help answer a very different question: What happens after this company charges customers? For some merchants, there is almost no interval between payment and completion. For others, a customer may pay weeks or months before receiving the product or service. During that interval, the customer obligation remains open. If the merchant cannot ultimately perform, there may be refunds, customer complaints or payment disputes. Card-network rules specifically contemplate disputes in which goods or services were paid for but not received. Mastercard's current merchant chargeback guide, for example, separately addresses "Goods or Services Not Provided" and future travel services. Visa likewise recognizes evidence designed to establish that merchandise, digital products, transport, and travel or entertainment services were actually received or used. Its merchant dispute guidance includes different evidence structures for delivered physical goods, downloaded digital goods, passenger transport, and travel-and-entertainment transactions. The underwriting relevance is therefore not simply: Does this merchant ship? It is: How much customer obligation can exist between payment and fulfilment, how reliably does the merchant complete that obligation, and what evidence exists to demonstrate completion?

Payment-to-fulfilment exposure: the timing matters Consider the operational sequence: Customer pays → merchant has an outstanding customer obligation → product or service is delivered → obligation is completed The length and uncertainty of the middle period can matter. A merchant shipping stocked consumer goods within a short operating cycle presents a different fulfilment pattern from a travel company accepting payment today for a service many months later. That does not mean long fulfilment automatically makes a merchant unacceptable. It means the underwriter may need to understand the exposure. Adyen provides a concrete provider-specific example of this logic. Its terms define an "Uncompleted Order Amount" around transactions for which products or services have not yet been delivered or certain customer rights remain open. Its terms also state that Adyen may request current or expected delivery dates and estimates of the average time between transaction authorization and delivery, using that information in its assessment of the uncompleted-order exposure and related deposit level. That is Adyen's documented framework, not a universal formula used by every PSP. But it illustrates why an underwriter asking about fulfilment time is not necessarily asking an administrative question. The answer can help characterize how much paid-but-not-yet-completed business exists at a point in time. Useful merchant measurements

A merchant that has reliable operational data can make the fulfilment model easier to understand by defining metrics such as: Typical fulfilment time For the merchant's own data: Fulfilment completion timestamp − defined payment timestamp The merchant should specify whether the payment timestamp means authorization, capture, order payment, or another clearly defined event. Traceable fulfilment rate Completed orders with retrievable fulfilment evidence ÷ relevant completed orders Delayed fulfilment rate Orders completed after the merchant's promised date ÷ relevant fulfilled orders Cancellation or refund rate The merchant should define whether this is measured by transaction count or transaction value and use the definition consistently. No universal acceptable benchmark should be inferred from these measures. Their first purpose is to make the merchant's own operation measurable and explainable. Payment confirmation is not proof of fulfilment One of the most important distinctions in onboarding is between proving the payment and proving what happened afterward. A payment record can establish that: * an order was charged; * a transaction was authorized or captured; * money was paid; or * a payment event occurred. It does not, by itself, establish that the customer's order was fulfilled. The evidence chain is different: Payment confirmation proves the payment event Order record proves what the customer ordered Fulfilment record helps prove what happened to that obligation Completion evidence

helps establish that the promised product or service reached the relevant fulfilment point A merchant submitting only successful-payment screenshots may therefore be answering the wrong underwriting question. Shipment is not necessarily confirmed delivery For physical goods, another critical distinction is: Order placed ≠ shipment created ≠ parcel dispatched ≠ customer receives parcel A tracking number can be useful evidence, but the existence of a tracking number alone does not necessarily demonstrate successful delivery. A more informative evidence chain could include: 1. Merchant order number. 2. Transaction or payment reference. 3. SKU or merchandise information. 4. Warehouse or fulfilment event. 5. Carrier. 6. Tracking identifier. 7. Dispatch timestamp. 8. Delivery status and timestamp. 9. Delivery destination or collection record where appropriate. 10. Exception, return, refund, or dispute outcome if relevant. Current Stripe dispute guidance reflects this distinction by separately identifying shipping documentation, shipping date, carrier, tracking number, and other evidence related to the recipient's possession of the goods. Visa's merchant guidance also demonstrates why "signed delivery receipt" should not be treated as the only possible evidence. For certain card-absent transactions, its compelling-evidence framework allows evidence that an item was delivered to a qualifying address and explicitly notes that a signature is not required in that particular evidence category.

The merchant lesson is not that signatures are unnecessary in every situation. It is that fulfilment evidence should be matched to the actual transaction, provider request, and applicable rules rather than reduced to one supposedly universal document. Physical-goods fulfilment evidence For an ecommerce merchant, the operational question is usually: Can this order be traced from payment through dispatch to delivery or another valid completion outcome? Potential evidence can include: * order-management records; * warehouse-management records; * pick-and-pack records; * carrier manifests; * shipping labels; * carrier tracking; * delivery confirmation; * signed receipts where applicable; * click-and-collect pickup records; * customer communications; * replacement records; * return records; and * refund records. Not every provider will request all of these. The strongest onboarding package is generally not the one with the greatest number of screenshots. It is the one in which the underwriter can understand the relationship between: payment → order → fulfilment event → completion Common physical-goods evidence gap A merchant exports hundreds of tracking numbers but does not show which payment or order corresponds to each tracking number. The evidence may be genuine, yet still leave the underwriting question unresolved. A useful fulfilment sample should make the linkage obvious. Digital goods: access and usage are different concepts

Digital businesses do not have a parcel to follow, but they often generate richer timestamped operational evidence than physical merchants. Potential records can include: * account creation; * entitlement provisioning; * software-license activation; * download event; * login; * IP information where appropriately collected and permitted; * device information where appropriately collected; * content access; * feature usage; * subscription status; * service logs; * account history; and * customer-support interaction. Stripe's current dispute documentation explicitly recommends access or activity logs showing that a customer accessed or downloaded a digital product after payment, including useful contextual data such as timestamps. Visa's digital-goods compelling-evidence guidance likewise recognizes successful downloads and associated transaction or device data as possible evidence within its specific dispute framework. Access is not always the same as usage Suppose a SaaS merchant creates a customer account immediately after payment. That may prove that access was provisioned. A later login or usage event can demonstrate that the service was actually accessed or used. Which event matters depends on what the merchant promised. If the contracted obligation is to make software available, provisioning may be central. If the merchant claims customers actively consume an ongoing service, usage records may give a fuller picture.

An underwriter should not have to infer the merchant's fulfilment definition from a raw server-log export. The merchant should explain what each event means. Online courses and other digital-service hybrids An online course demonstrates why fulfilment must be defined before evidence is selected. If the merchant sells permanent access to a prerecorded course, providing access may represent much of the promised obligation. If the product includes: * weekly live classes; * instructor feedback; * certification; * tutoring; * scheduled coaching; or * a program delivered over several months, then creating a login may show only the beginning of fulfilment. Potential evidence could instead map the full delivery model: Enrollment → access enabled → lessons available → sessions attended → assignments or milestones completed → contracted program delivered The useful evidence depends on what customers were actually sold. Service businesses: prove performance, not shipment Professional and offline services require another evidence model. Potential records may include: * signed work orders; * appointment records; * project-management records; * service tickets; * technician logs; * deliverables; * milestone approvals; * customer acceptance; * completion certificates; * usage records; * dated correspondence; and * contracts describing the service period.

Stripe's current evidence guidance for offline services describes documentation showing that the service was provided, including the date on which the customer received or began receiving it, with examples such as contracts, work orders, or other written agreements. The exact evidence must still match the merchant's operating model. A consulting firm claiming that a project was completed should ideally be able to connect: payment → engagement → agreed work → completed work rather than merely provide an invoice showing that the customer was billed. Booking confirmation is not service completion Travel and other future-delivery businesses create a particularly important distinction: Reservation created ≠ future service performed A hotel booking confirmation proves that a reservation existed. It does not necessarily prove that the guest stayed. An airline ticket proves that transportation was booked. It does not necessarily prove that the passenger travelled. Network dispute frameworks reflect this distinction. Visa's guidance identifies evidence that passenger-transport services were provided, including events such as a boarding pass being scanned and certain related travel activity. It separately addresses travel-and-entertainment evidence tied to services actually being provided.

Mastercard's merchant chargeback guide likewise distinguishes situations in which travel services were not provided from evidence supporting the fact that the travel service was actually provided, refunded, or otherwise covered under the relevant framework. For underwriting purposes, future-delivery merchants should therefore be ready to explain both: How is a future obligation created? and What system records show that the obligation was ultimately completed? Supplier evidence is not fulfilment evidence This distinction is especially important for ecommerce merchants. A supplier invoice may help answer: Can the merchant obtain the merchandise it sells? A delivery record helps answer: Did the merchant complete the customer's order? Those are related but different questions. Supplier agreements, purchase orders, distributor agreements, or inventory invoices belong primarily to the supply evidence layer. Customer delivery, digital access, service completion, or booking-performance records belong primarily to the fulfilment evidence layer. For a deeper discussion of the first question, see Supplier Agreement Requirements. For the broader set of evidence categories a PSP may request during onboarding, see Documents Needed for PSP Approval. The Fulfilment Evidence Ladder Merchants can organize their evidence using a six-stage model. 1. Order accepted Question: What did the customer agree to purchase? Possible evidence: * order ID; * order confirmation; * transaction reference;

* product or service description; * price; * purchase timestamp; * relevant customer terms. This establishes the obligation. 2. Product or service prepared Question: Did the merchant begin operational performance? Possible evidence: * warehouse allocation; * inventory reservation; * work order; * service scheduling; * account provisioning; * booking preparation. This shows progress but normally does not establish completion by itself. 3. Dispatch or access provided Question: Did the merchant make the product or service available? Possible evidence: * carrier acceptance; * dispatch event; * download enabled; * license activated; * account enabled; * appointment commenced. Again, this may or may not be the contractual fulfilment point. 4. Customer receives or accesses Question: Is there evidence connecting the customer with receipt or access? Possible evidence: * carrier delivery; * pickup; * successful download; * login; * attendance; * check-in; * boarding; * service-use record. Visa and Stripe both distinguish evidence according to whether the transaction involves physical goods, digital products, or services, reinforcing why this stage needs business-model-specific records. 5. Obligation completed Question: Has the merchant done everything it promised under the relevant order? Potential evidence: * final delivery; * completed service; * completed milestone; * check-out or travel completion; * completed digital entitlement; * customer acceptance; * contract-completion record.

This is the stage merchants should define most carefully. "Completed" will not mean the same thing for every business. 6. Refund or dispute outcome where relevant Question: What happened when fulfilment did not proceed normally? Potential evidence: * cancellation; * return; * replacement; * refund; * partial refund; * customer communication; * dispute outcome. This stage matters because an evidence sample consisting only of perfect orders can obscure how the merchant handles exceptions. Adyen's published terms provide one example of why payment providers care about maintaining transaction, ordering, delivery, shipping, invoice, and customer-contact records that can later be examined in connection with chargebacks, suspected fraud, or other information requests. A visual version of the Fulfilment Evidence Ladder Order accepted ↓ Prepared ↓ Dispatched / access provided ↓ Received / accessed ↓ Customer obligation completed ↓ Refund / dispute outcome if applicable The strongest evidence architecture connects each stage to the same: payment reference + order reference + customer obligation That makes the fulfilment story reconstructable without forcing a reviewer to manually reconcile unrelated files. What makes a fulfilment sample representative? When an underwriter asks for fulfilment evidence, merchants should follow the provider's requested scope. If the request allows the merchant to assemble representative examples, avoid selecting records solely because they are the cleanest possible orders.

Depending on the underwriting question, a useful sample may need to represent differences across: * dates; * product types; * countries; * order sizes; * fulfilment channels; * carriers; * normal orders; * delayed orders; * cancellations; * refunds; or * other relevant operational outcomes. There is no universal number of records that merchants should submit. If the PSP asks for a specific sample size, date range, transaction set, or format, follow that request rather than substituting an internally preferred sample. The goal is not to overwhelm the reviewer with data. The goal is to demonstrate that the merchant's stated fulfilment process can be reconciled to actual customer orders. Common fulfilment-evidence gaps Evidence cannot be linked to the payment A warehouse report may prove that parcels leave the warehouse without demonstrating which payment funded which order. Merchant action: include common identifiers that allow payment, order, and fulfilment records to be reconciled. Shipment is presented as delivery A dispatch record shows that fulfilment started. It may not show that the customer received the merchandise. Merchant action: distinguish dispatch status from final carrier or collection status. Account creation is presented as digital usage An account may exist without ever being accessed. Merchant action: define whether account provisioning itself completes the merchant's obligation. If not, preserve the later evidence that does. Booking confirmation is presented as completed travel

A reservation confirms a future obligation. Merchant action: retain evidence from the later service event as well. Supplier records are substituted for customer fulfilment A supplier invoice can demonstrate product sourcing without demonstrating delivery to the buyer. Merchant action: treat supply and fulfilment as separate evidence chains. Evidence covers the wrong legal entity The PSP is underwriting Merchant A, but fulfilment exports or customer contracts identify Merchant B. That does not necessarily mean the arrangement is invalid, but the relationship may need to be explained. Merchant action: reconcile entity names before submission and explain legitimate group-company or operational relationships. Evidence is impossible to interpret Large spreadsheets, screenshots without identifiers, truncated carrier records, and raw logs without explanation can contain the right information while failing to answer the reviewer efficiently. Merchant action: provide a concise evidence key explaining the fields, systems, statuses, and identifiers. Exception handling is invisible A merchant can have an effective fulfilment operation while still experiencing failed deliveries, cancellations, refunds, or other exceptions. Merchant action: be able to show what happens when fulfilment fails instead of implying that exceptions never occur. How merchants should prepare proof of fulfilment before a PSP asks for it 1. Define the customer obligation

Owner: Merchant operations, product, finance, or legal/commercial owner as appropriate. Write down exactly what the customer purchases and the event at which the merchant considers the obligation completed. Do this separately for materially different products or services. 2. Map the fulfilment journey For each model, map: payment → order → operational event → delivery/access/performance → completion → exception/refund Identify which internal system produces evidence at every stage. 3. Make payment and fulfilment data reconcilable The PSP should not need to guess which tracking record, account event, booking, or service record belongs to which transaction. Where operationally possible, maintain common references such as: * transaction ID; * merchant order ID; * booking ID; * subscription ID; * customer account ID; or * fulfilment ID. 4. Measure the payment-to-fulfilment interval Calculate it from merchant data using clearly defined start and completion events. Do not describe a forecast or target fulfilment time as historical actual performance. 5. Test whether evidence is retrievable Pick historical orders internally and ask: Could we reconstruct what happened to this customer's obligation today? If the answer requires searching five systems manually with no common reference, the merchant has identified an operational evidence problem before the underwriter does. 6. Include exceptions in the model Document what happens when: * stock is unavailable; * a carrier loses a shipment; * software access fails;

* an appointment is rescheduled; * travel is cancelled; * the customer requests a refund; or * the merchant cannot complete the obligation. 7. Run a consistency review Check that the: * legal entity; * trading name; * website; * payment records; * customer terms; * fulfilment records; * supplier relationships where relevant; and * settlement arrangements describe the same merchant relationship or have an explainable reason when they do not. 8. Answer the specific underwriting question If another document is requested, ask: "What specific fulfilment or underwriting question remains unresolved?" Then submit evidence that answers that question rather than automatically resending the entire evidence package. 9. Use the provider's approved submission method Fulfilment records can contain customer information. Provide only information appropriate to the request and use the PSP's required secure channel and data-handling process. What good fulfilment evidence can—and cannot—establish Good evidence can help an underwriter understand: * how fulfilment works; * what event represents completion; * whether the process appears operational; * whether historical orders can be traced; * how long customer obligations remain open; * how exceptions are handled; and * whether the merchant's description is consistent with operating records. It does not automatically establish that: * every future transaction will be fulfilled; * the merchant has no other underwriting exposure;

* the business fits a particular provider's risk appetite; * the merchant satisfies every acquiring requirement; or * the application must be approved. Proof of fulfilment is one part of a broader underwriting assessment. For online merchants, that wider assessment may also involve the website, products, customer journey, refund model, transaction profile, fraud exposure, disputes, geography, and other characteristics. See Underwriting for Online Merchants for that broader subject. Proof of fulfilment versus proof of payment versus supplier evidence Evidence Primary question it helps answer Payment confirmation Did a payment occur? Order record What did the customer purchase? Supplier invoice or agreement Can the merchant obtain what it sells? Dispatch record Did shipment or delivery activity begin? Delivery/access record Did the customer receive or access the product or service? Completion record Did the merchant complete the promised obligation? Refund record Was the customer's payment returned when applicable? Keeping these questions separate prevents one of the most common onboarding problems: submitting a legitimate document that nevertheless does not prove what the merchant thinks it proves. FAQ: Proof of fulfilment requirements What counts as proof of fulfilment for a physical-goods merchant?

Depending on the provider and underwriting request, relevant merchant fulfilment evidence may include shipment records, carrier tracking, delivery confirmation, pickup records, warehouse information, customer communications, or other records connecting the order to delivery. A tracking number may be useful, but a tracking number existing is not necessarily the same as demonstrating completed delivery. Current PSP and network dispute guidance uses multiple forms of shipping and delivery evidence rather than treating one document as universally sufficient. What counts as proof of fulfillment for a digital product? Potential evidence can include account provisioning, download events, activation records, login records, server logs, or product-usage information, depending on what the merchant promised the customer. Stripe and Visa both recognize digital access/download or activity information within their respective dispute-evidence frameworks. Those dispute rules should not be interpreted as a universal PSP onboarding checklist. Is a payment receipt proof that the order was fulfilled? No. A payment receipt establishes information about the transaction. Fulfilment evidence addresses what happened to the customer's product or service obligation after the payment. Is a booking confirmation proof of fulfilment for a hotel or travel merchant?

A booking confirmation establishes that a reservation was created. It does not necessarily demonstrate that the underlying hotel stay, flight, tour, rental, or other service was performed. Visa and Mastercard's dispute frameworks distinguish the purchase or booking from evidence that travel or transportation services were actually provided. Why might a PSP ask how long fulfilment takes? The period between customer payment and completion can help a payment provider understand outstanding customer obligations and potential exposure associated with goods or services that have not yet been delivered. Adyen's published terms provide one provider-specific example: they permit collection of expected delivery dates and authorization-to-delivery timing information for use in assessing its defined "Uncompleted Order Amount." Other providers may use different methods, terminology, or requirements. Does every PSP require proof of fulfilment during onboarding? No universal fulfilment-document requirement should be assumed. A provider may request fulfilment evidence depending on the merchant, business model, transaction pattern, geography, acquiring arrangement, product, delivery model, or risk assessment. Current provider onboarding documentation demonstrates that verification requirements can vary according to merchant circumstances and jurisdiction. Can a supplier invoice count as proof of fulfilment? A supplier invoice can help demonstrate that a merchant has sourced or can source merchandise.

It does not necessarily prove that a particular customer received the product. The distinction is: supplier evidence → ability to source fulfilment evidence → completion of the customer obligation For a deeper treatment of sourcing evidence, see Supplier Agreement Requirements. How many fulfilment records should a merchant submit? There is no defensible universal sample size. Use the number, period, transactions, and format requested by the PSP or underwriting party. Where the merchant is permitted to choose representative records, ensure the sample meaningfully represents the operation rather than selecting only unusually clean transactions. The strongest proof of fulfilment starts before onboarding Merchants often treat fulfilment evidence as something to create when an underwriter requests it. A stronger approach is to treat fulfilment evidence as a normal output of the merchant's operation. Every successful transaction should ideally leave an understandable trail: what the customer purchased → when the customer paid → what the merchant had to deliver → what happened operationally → when the obligation was completed → what happened if it was not completed normally That evidence can make a PSP's questions easier to answer. More importantly, it gives the merchant itself a better view of the customer obligations sitting behind its payment volume. The objective is not to manufacture a perfect application package or overwhelm the reviewer with documents.

It is to make the commercial reality of the business verifiable.

"Which document do you want?" It is: "What are you trying to establish about our customer obligations, and which evidence would resolve that question?" That is the difference between treating merchant onboarding as paperwork and treating it as what it actually is: an evidence-based assessment of a merchant's ability to support the payment activity it wants to process. Disclaimer: This article provides general information and does not constitute legal, regulatory, financial, tax, or compliance advice. Merchant onboarding and underwriting requirements vary by jurisdiction, provider, acquirer, business model, and individual circumstances. Merchants should confirm applicable requirements with qualified advisers and the relevant payment providers, acquirers, banks, regulators, and authorities. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

I used the attached editorial brief as the controlling specification for this article. PUBLICATION METADATA — NOT ARTICLE COPY SEO title: Proof of Fulfilment for PSP Onboarding: What It Is and Why Underwriters Ask for It Meta title: Proof of Fulfilment Requirements for PSP Onboarding Meta description: Learn what proof of fulfilment means in PSP onboarding, why underwriters request it, and what evidence works for physical goods, digital products, services, and travel. Suggested URL slug: /merchant-onboarding/proof-of-fulfilment-requirements/ EDITORIAL / SEO NOTES — NOT ARTICLE COPY Suggested internal links The strongest contextual links are Supplier Agreement Requirements from the supplier-vs-fulfilment distinction; Documents Needed for PSP Approval from the discussion of evidence categories; Underwriting for Online Merchants after explaining the limits of fulfilment evidence; and Why Merchants Are Rejected by PSPs where the article explains that good fulfilment evidence does not guarantee provider fit or approval. I would avoid linking heavily to Processing History Requirements in this article because fulfilment evidence rather than historical payment performance is the owned territory. Likewise, the detailed acceleration tactics should remain primarily in How to Accelerate Merchant Onboarding. Suggested supporting visual Fulfilment Evidence Ladder A six-stage process visual:

1. Order accepted → 2. Prepared → 3. Dispatch/access → 4. Received/accessed → 5. Obligation completed → 6. Refund/dispute outcome Under each stage, show three small example rows: Stage Physical goods Digital Service / travel Order accepted Order ID Subscription/order Booking/work order Prepared Pick/pack Account created Scheduled Dispatch/access Carrier handoff License/access enabled Service begins Received/accessed Delivery event Login/download Check-in/attendance Completed Delivered order Promised entitlement delivered Service performed Exception Return/refund Cancellation/refund Cancellation/refund This visual reinforces the article's differentiating thesis without becoming a generic document checklist. Recommended alt text: “Fulfilment Evidence Ladder showing how payment orders progress from order acceptance through preparation, dispatch or access, receipt, completion, and refund or dispute outcomes for physical goods, digital products, and services.” Sources / research references The most important primary sources used were: 1. Adyen — Terms and Conditions. Particularly useful because Adyen explicitly defines delivery date and uncompleted-order exposure, may request expected delivery timing, and requires transaction/order/delivery records in its documented merchant framework. 2. Checkout.com — Verify Your Business, updated May 18, 2026. Useful for establishing that actual onboarding evidence requirements vary by jurisdiction and merchant circumstances rather than forming one universal PSP document list.

3. Checkout.com — Service Terms. Current acquiring terms distinguish agreed products/services, delivery timing, transaction record retention, payment-method rules, and risk-management measures. 4. Stripe — Dispute reason/evidence documentation. Useful operational evidence examples for physical products, digital products/services, and offline services, including shipping records, activity logs, work orders and service documentation. These were deliberately treated as examples of evidence architecture—not as Stripe onboarding requirements. 5. Visa — Dispute Management Guidelines for Visa Merchants. Useful primary network evidence showing separate treatment of physical delivery, digital downloads, passenger transport, and travel-and-entertainment services. 6. Mastercard — Chargeback Guide, Merchant Edition, May 13, 2025. Supports the distinction between payment/booking and goods or services actually being provided, including future travel-service exposure. 7. Adyen — PayPal chargeback documentation. PayPal's ProofOfFulfillment evidence category, as documented by Adyen, can involve shipping details, tracking, delivery confirmations, or other evidence of successful fulfilment. Again, this is dispute evidence rather than a claim about universal onboarding requirements.

Claims requiring legal / compliance / risk review Provider-specific references should receive a final currency check immediately before publication because PSP terms and network rules can change. In particular, revalidate the cited Adyen delivery/exposure provisions and the current Visa/Mastercard dispute guidance at publication time. It would also be useful for an underwriter or merchant-risk specialist to review the terminology around payment-to-fulfilment exposure and for a merchant operations lead or ecommerce operations specialist to review the Fulfilment Evidence Ladder. These are recommended reviewers, not contributors whose review is claimed to have already occurred. Editorial differentiation check This article now has a clear owned territory: A merchant should read this article rather than another Merchant Onboarding article when they need to understand what operational evidence demonstrates that paid customer obligations are actually completed across physical, digital, service, and future-delivery business models. That keeps sourcing ability with Supplier Agreement Requirements, general documents with Documents Needed for PSP Approval, and general risk interpretation with Underwriting for Online Merchants, reducing cluster cannibalization.