Name the two records before the test
Record the payment identifier, appointment identifier, payment state and its provider or service source, the list of states the named appointment-confirmation policy accepts, that policy's owner, expected confirmation, observed appointment confirmation, and mismatch owner. Do not infer that an appointment exists because a client showed a successful payment screen.
Stripe's PaymentIntent lifecycle illustrates that a payment integration can have distinct states. It describes Stripe's API, not your booking policy, processor, or fulfillment behavior.
Exercise one safe boundary
- Obtain approval for one non-production booking fixture with no customer data.
- Record distinct payment and appointment identifiers before starting.
- State the payment state, the policy-owned list of states allowed to confirm an appointment, and the appointment result a reviewer expects to inspect.
- Run the bounded procedure and record the observed appointment result.
- Name who decides what happens if the records disagree.
The local checker makes the minimum receipt visible:
node --test sites/howtox.com/evidence/P141/payment-appointment-receipt.test.mjs
It does not charge a card, create an appointment, verify a webhook, or prove a refund path.
Stop when a confirmation has no authority
Pause rollout if the team cannot name the two records, payment-state source, policy owner, accepted-state list, expected confirmation, observation, or reconciliation owner. Staff need a clear record and recovery route, not a guess based on a screen or email.
For the calendar copy, see Test Booking-to-Calendar Sync Before Staff Rely on It. For a time-zone change after confirmation, see Test Appointment Rescheduling Across Time Zones.
Does this receipt prove a payment was collected or an appointment is secure?
No. It makes one proposed verification boundary inspectable. Payment authorization, availability, configuration, notification delivery, and production recovery require separate approved evidence.