End-to-End Access, Payment, and Delivery Test Script

A dashboard can show a successful payment while a learner still cannot start the first lesson. A live room can open while the promised replay has no owner. A refund request can be created while the business record, learner access, and support response disagree.

Use this script to record one defined buyer journey from promise to recovery. It cannot tell you which platform, account, payment method, or entity will work in China. It makes a narrower question answerable: under dated, recorded conditions, did this specific offer complete the promises made to this specific kind of learner?

This page is deliberately downstream of the platform-test framework. That framework decides what promise should be tested; this one records the result.

Begin with one offer, not an abstract “China route”

Define a bounded offer. It might be an invitation-only workshop, one self-paced module, or a named enterprise session. State the intended learner, the first promised action, the materials or room required, the stated support path, and the result that would make the team proceed, repair and retest, or pause.

Do not combine a free resource, a public checkout, and a live cohort into one test and call the outcome a platform conclusion. They require different journeys.

Before anyone clicks, create a test identity that does not expose a customer’s credentials or payment data. Record the date, time zone, device, browser/app, relevant network condition, and VPN/proxy state. A VPN-assisted pass is not evidence of a non-VPN learner experience.

The six checkpoints

Use PASS, PARTIAL, FAIL, or NOT TESTED. “Not tested” is a limitation, not a defect; it tells a later reader what must not be claimed.

For every checkpoint retain seven fields: the step, the decision affected, result, evidence level, a sanitised evidence reference, accountable owner, and timestamp. A green result without an owner or a time is not a usable operating record.

Keep evidence proportional. A dated screen capture, a route log, or a sanitised message record can be sufficient for an early test. Do not collect private payment details, learner content, or credentials merely because a checklist has a field for evidence. The record should make the decision reviewable while keeping the test narrow and respectful of privacy.

The owner should be a real role, not “the team.” If the route fails at 8 p.m., a named person must know whether they can correct the failure, escalate it, or pause the offer. That clarity is especially important when several providers each show a different partial success.

1. Offer and dependencies

Start from the promise. Does the sales or invitation page express what the learner gets, when they get it, and the first action they must take? Record every dependency that is necessary to that promise: a form, email verification, login, calendar, video, download, or another domain.

Stop when a required dependency is materially unavailable. Do not silently route the learner somewhere else and call the original promise passed. If a manual handoff is accepted for a tightly controlled pilot, record who performs it, how quickly, and why it is acceptable for this offer.

2. Identity and communications

Record sign-up, verification, password recovery where relevant, and arrival time and sender identity of essential messages. A completed payment paired with an unusable identity is a delivery failure, not an administrative inconvenience.

Use a dedicated test account wherever the route permits. Retain only sanitised evidence and do not turn a test into a reason to collect unnecessary personal data.

3. Checkout or commercial handoff

For a public offer, record the displayed payment method and currency, exact stopping point, and sanitised order evidence. For a named enterprise session, record the appropriate commercial handoff—such as approved scope, invoice route, named participants, and delivery confirmation—rather than forcing a consumer-wallet test that is irrelevant to the offer.

Stripe documents that supported payment methods can depend on configuration conditions; Teachable documents conditions for its own payment service.¹ These facts justify checking an exact setup. They do not predict whether a particular route will work for your business or buyer.

4. Entitlement and first access

After the payment or invitation event, check actual enrolment: welcome communication, dashboard or library, schedule, and first required action. Distinguish a payment record from the entitlement it was supposed to create.

If an operator manually repairs access, retain the response time, authority, and repeatability. The workaround may be acceptable in a pilot. It is not automatically an acceptable design for a self-serve offer.

5. Delivery and support

Complete the core promise. Open the first material, join the live session when applicable, use the required download or exercise, and send one ordinary support question through the stated path. For a cohort, distinguish the room, broadcast, interaction, and replay promises; the room/broadcast/replay guide covers that separation.

Stop when the learner cannot perform the core action or cannot obtain a clear answer within the threshold the offer states. Do not mark delivery as passed only because an operator can see a payment or attendance record.

6. Recovery and reconciliation

Recovery is where superficial tests end. Define who owns a cancellation, refund request, duplicate account, failed recurring payment, access correction, and final reconciliation between the commercial, course, and support records.

WeChat Pay’s refund documentation is useful only as a state-boundary example: a refund request and a later status are separate documented states.² It does not establish that any merchant, offer, or payment route may use WeChat Pay. Its lesson for the test record is simply that “a request was sent” and “the exception was resolved” should not be treated as the same result. For refund-specific exception logic, see why a payment button is not a refund operation.

Read the result conservatively

Close with one decision only:

• Proceed to a bounded pilot when every required promise has a recorded pass or an explicitly accepted manual control.
• Repair and retest when a named failure can be corrected and the changed route can be observed again.
• Pause when a required promise has no accountable owner, evidence, or recovery path.

The conclusion should be narrow: “Under these recorded conditions, this offer did or did not complete the promises made.” It should never become “the platform works in China.”

When the script is the wrong tool

A short exploratory demonstration may not include payment, entitlement, or a durable support promise. Use only the checkpoints the honest offer contains, and mark the rest not tested. Conversely, an enterprise purchase may require a separate procurement, security, contractual, tax, or legal review; this script cannot replace those disciplines.

It also cannot prove demand, price fit, permission to distribute creator content, regulatory compliance, data-protection compliance, learning outcomes, or revenue.

The discipline is intentionally modest: a recorded failure is more valuable than an optimistic claim because it tells the team exactly what should be repaired, retested, or removed from the promise before more people encounter it.

Next step: define one concrete offer using the platform-test framework, then capture its actual route with this script. If you need an independent, bounded review before expansion, request a validation review.

Sources and limits