The China Buyer-Route Test: Record the Handoff, Not Just the Payment

Short answer: 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—offer, identity, payment where applicable, entitlement, delivery, support and recovery—or when any manual control is explicitly accepted and recorded.

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.

The claim this script makes

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

Use it after defining the promise with Test the Buyer Promise, Not the Course Platform. 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 to keep that diagnosis narrow.

The record to keep

For each checkpoint, record the same fields. PASS, PARTIAL, FAIL and NOT TESTED are OriBridge internal test labels; they are not provider states.

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.

The seven handoffs

1. Offer comprehension

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.

2. Identity and essential messages

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.

3. Payment, if payment belongs in this route

Record displayed currency and method, the precise stop point and the authorisation status. Stripe’s 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.¹

4. Entitlement

After payment or invitation, does the exact buyer receive the access they were promised? This is where “payment succeeded” often diverges from “course delivered.”

5. First useful learning action

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.

6. Support

Can the buyer use the support route stated in the offer, and is there a response owner? Do not substitute an operator’s private message for the route you expect a real buyer to use.

7. Recovery and reconciliation

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’s public Memberships FAQ says that, within that product, three failed charge attempts result in automatic unenrolment.² That is a product-specific example of why payment and access should not be presumed identical.

A post-mortem that points somewhere useful

When a route fails, do not ask, “Did China reject the product?” Ask where the buyer last had a reliable state.

This is an editorial diagnostic framework, not a causal analysis of a real customer. The value is that it prevents the wrong repair.

Two routes, two honest tests

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 “China-ready.” They simply make different promises.

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.

The result should be a decision, not a dashboard

Close the record with exactly one of three outcomes:

• Proceed to a bounded pilot: each required state passed or has an explicitly accepted manual control.
• Repair and retest: the failure has a named owner and a retestable fix.
• Pause: a required payment, access, delivery, support or recovery responsibility remains unresolved.

The conclusion is not “the platform works in China.” It is: under the recorded conditions, this offer did or did not keep the promises a buyer was asked to rely on.

This script cannot establish platform eligibility, legal compliance, tax treatment, buyer demand, pricing fit, course quality or distribution rights. It also does not replace a delivery-design decision such as Live Cohort, Room, Broadcast and Replay. If you need an independent route review before expanding a test, request a validation review.

Sources and limits