{"id":105,"date":"2026-08-12T19:52:08","date_gmt":"2026-08-12T11:52:08","guid":{"rendered":"https:\/\/oribridge.org\/blog\/?p=105"},"modified":"2026-09-01T17:42:47","modified_gmt":"2026-09-01T09:42:47","slug":"end-to-end-access-payment-and-delivery-test-script","status":"publish","type":"post","link":"https:\/\/oribridge.org\/blog\/end-to-end-access-payment-and-delivery-test-script\/","title":{"rendered":"The China Buyer-Route Test: Record the Handoff, Not Just the Payment"},"content":{"rendered":"

Short answer:<\/strong> a payment success screen is only one state in a buyer route. A route is ready for a bounded pilot only when the buyer can complete every required handoff\u2014offer, identity, payment where applicable, entitlement, delivery, support and recovery\u2014or when any manual control is explicitly accepted and recorded.<\/p>\n

A customer can want the course and still lose the sale before they ever see a lesson. They may stop at identity verification. They may complete payment but never receive access. They may reach the first live session and find no way to recover from a broken link. If those states are collected in different dashboards, the team can mistake a payment record for a completed purchase.<\/p>\n

The claim this script makes<\/h2>\n

The first operational record should be a chain of buyer-visible states, each with an owner and evidence\u2014not a list of platform features.<\/strong> This script does not recommend a platform or payment method. It makes the route falsifiable.<\/p>\n

Use it after defining the promise with Test the Buyer Promise, Not the Course Platform<\/a>. Run it for one offer only: one paid workshop, one self-paced module, or one invitation-only enterprise session. Combining several products turns a test into an argument. If the buyer fails at checkout, use When Checkout May Be Hiding a China Course Signal<\/a> to keep that diagnosis narrow.<\/p>\n

The record to keep<\/h2>\n

For each checkpoint, record the same fields. PASS, PARTIAL, FAIL and NOT TESTED are OriBridge internal test labels; they are not provider states.<\/strong><\/p>\n

\n\n\n\n\n\n\n\n\n\n
Field<\/th>\nWhat it means<\/th>\n<\/tr>\n<\/thead>\n
Buyer promise<\/td>\nWhat the learner expects at this point<\/td>\n<\/tr>\n
State<\/td>\nPASS, PARTIAL, FAIL, or NOT TESTED<\/td>\n<\/tr>\n
Evidence<\/td>\nSanitised timestamp, system receipt, or reproducible observation<\/td>\n<\/tr>\n
Owner<\/td>\nWho can repair, accept, or stop the route<\/td>\n<\/tr>\n
Next test<\/td>\nThe smallest action that removes the uncertainty<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Do not record personal or payment details beyond what your privacy and evidence rules allow. A screenshot with card data is not stronger evidence than a sanitised receipt reference.<\/p>\n

The seven handoffs<\/h2>\n

1. Offer comprehension<\/h3>\n

Can the named buyer understand what they receive, when, and what the next action is? A page loading is not enough if the offer is unclear.<\/p>\n

2. Identity and essential messages<\/h3>\n

Can the buyer create, receive, recover and use the identity required by the offer? Record the sender, expected message and threshold. A paid buyer with an unusable login has not received the product.<\/p>\n

3. Payment, if payment belongs in this route<\/h3>\n

Record displayed currency and method, the precise stop point and the authorisation status. Stripe\u2019s public documentation makes clear that payment-method support is configuration-dependent; it cannot tell a reader that a particular entity, account or route is eligible.1<\/a><\/sup><\/p>\n

4. Entitlement<\/h3>\n

After payment or invitation, does the exact buyer receive the access they were promised? This is where \u201cpayment succeeded\u201d often diverges from \u201ccourse delivered.\u201d<\/p>\n

5. First useful learning action<\/h3>\n

Can the learner open the first material, join the scheduled event or complete the first required exercise? A dashboard tile is not delivery if the buyer cannot use it.<\/p>\n

6. Support<\/h3>\n

Can the buyer use the support route stated in the offer, and is there a response owner? Do not substitute an operator\u2019s private message for the route you expect a real buyer to use.<\/p>\n

7. Recovery and reconciliation<\/h3>\n

If an order, access record and support record disagree, who can reconcile them? Where refund, cancellation, recurring payments or duplicate accounts are within scope, test them only through authorised processes; otherwise label them NOT TESTED. Teachable\u2019s public Memberships FAQ says that, within that product, three failed charge attempts result in automatic unenrolment.2<\/a><\/sup> That is a product-specific example of why payment and access should not be presumed identical.<\/p>\n

A post-mortem that points somewhere useful<\/h2>\n

When a route fails, do not ask, \u201cDid China reject the product?\u201d Ask where the buyer last had a reliable state.<\/p>\n

\n\n\n\n\n\n\n\n\n
Last reliable state<\/th>\nThe next question<\/th>\nDo not jump to<\/th>\n<\/tr>\n<\/thead>\n
Buyer understood the offer but did not continue<\/td>\nIs the next action proportionate and reachable?<\/td>\nA full product rebuild<\/td>\n<\/tr>\n
Payment confirmed, no access<\/td>\nIs entitlement connected to the completed order?<\/td>\nMore translation<\/td>\n<\/tr>\n
Access exists, first activity fails<\/td>\nIs the promised delivery surface usable?<\/td>\nA demand conclusion<\/td>\n<\/tr>\n
Buyer gets stuck, operator fixes it manually<\/td>\nCan the control be owned and repeated?<\/td>\nA self-serve readiness claim<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

This is an editorial diagnostic framework, not a causal analysis of a real customer. The value is that it prevents the wrong repair.<\/p>\n

Two routes, two honest tests<\/h2>\n

A public course may require offer, checkout, account, access, materials and support. An enterprise pilot may instead require a sponsor, named participants, a scoped agreement, controlled enrolment and delivery confirmation. Neither route is inherently more \u201cChina-ready.\u201d They simply make different promises.<\/p>\n

Do not force an enterprise pilot through a consumer wallet test, and do not label a public self-serve route validated because staff can manually add a learner. The test must mirror the route that will actually be offered.<\/p>\n

The result should be a decision, not a dashboard<\/h2>\n

Close the record with exactly one of three outcomes:<\/p>\n