Stripe PaymentIntent
Status, amount, currency, customer reference and WooCommerce order metadata.
Synthetic lab fixture · no client data
WooCommerce + Stripe payment-state reconciliation lab
Reproduce one controlled mismatch: Stripe succeeds, the webhook path is acknowledged, and the expected WooCommerce order transition does not complete. Inspect the evidence and generate the same deterministic reconciliation result.
This is not a client case study or claimed production incident. Every ID, timestamp and state is synthetic.
Synthetic only
No client, customer or production-store data.
No credentials
The page does not accept keys, secrets or uploads.
No automatic fix
The expected result is evidence for manual review.
01 · Event clock
Timestamped synthetic timeline
The fixture uses one fixed UTC sequence so the reconciliation result can be reproduced without interpreting changing live data.
WooCommerce order created
Synthetic order WC-LAB-1042 enters pending payment with a £129.00 GBP total.
Stripe PaymentIntent created
pi_lab_7f3a_redacted carries metadata linking it to WooCommerce order 1042.
Stripe payment succeeds
The synthetic event payment_intent.succeeded is created in test mode.
Webhook delivery returns HTTP 200
The lab models an acknowledged event whose expected WooCommerce transition still does not complete.
Reconciliation check detects drift
Stripe remains succeeded while WooCommerce remains pending after the five-minute fixture window.
02 · State contract
Expected versus observed
Controls must agree before the state mismatch is meaningful. The lab deliberately preserves identity and amount controls while the order transition fails.
| Evidence field | Expected | Observed | Result |
|---|---|---|---|
| Stripe payment state | succeeded | succeeded | control |
| WooCommerce order state | processing | pending | mismatch |
| Order transaction ID | pi_lab_7f3a_redacted | absent | mismatch |
| Payment-complete order note | present | absent | mismatch |
| Amount and currency | 12900 / GBP | 12900 / GBP | control |
03 · Evidence map
Sources to inspect on a real store
The downloadable fixture covers the synthetic Stripe event and reconciliation output. A real review must preserve and compare the surrounding store-side evidence as well.
Stripe event envelope
Event ID, type, creation time, mode, request reference and object snapshot.
Webhook delivery record
Endpoint, attempt time and HTTP response. A 200 response alone does not prove the order changed.
WooCommerce order
Order status, total, currency, transaction ID, gateway fields and customer-safe reference.
Order notes and gateway logs
Payment-complete notes, validation errors, handler messages and status transitions.
Action Scheduler
Failed, pending or delayed background actions around the synthetic event window.
04 · Reconciliation protocol
Seven deterministic steps
Run the checks in order. The protocol stops at classification and never treats a mismatch as permission to edit the order.
- 01
Confirm fixture boundaries
Require synthetic=true and not_for_replay=true. Reject credentials, signatures and real customer data.
- 02
Normalize the time window
Read all timestamps in UTC and use the fixed 09:41:22–09:46:38 lab window.
- 03
Match the records
Join PaymentIntent pi_lab_7f3a_redacted to WooCommerce order 1042 through explicit metadata.
- 04
Check identity controls
Compare amount_minor=12900 and currency=GBP before interpreting payment state.
- 05
Compare the state transition
Map Stripe succeeded to the fixture's expected WooCommerce processing state, then record the observed pending state.
- 06
Inspect processing evidence
Check event delivery, the transaction ID, order notes, gateway logs and queued actions. Do not treat HTTP 200 as proof of completion.
- 07
Classify without mutation
Write payment_state_mismatch and manual_confirmation_before_order_edit to the CSV. Do not change the order.
05 · Static artifacts
Download and inspect the exact fixtures
The source data is shown here as well as provided as static files. No form, login or credential submission is required.
Synthetic Stripe event
Small JSON fixture with redacted lab IDs and an explicit not-for-replay boundary.
payment-intent-succeeded.fixture.json
{
"fixture_version": "1.0",
"fixture_id": "woo-stripe-lab-001",
"fixture_type": "synthetic_stripe_event",
"synthetic": true,
"not_for_replay": true,
"event": {
"id": "evt_lab_a91c_redacted",
"object": "event",
"api_version": "2024-06-20",
"created": 1783849297,
"livemode": false,
"type": "payment_intent.succeeded",
"pending_webhooks": 1,
"request": {
"id": "req_lab_42df_redacted",
"idempotency_key": "lab-order-1042-attempt-1"
},
"data": {
"object": {
"id": "pi_lab_7f3a_redacted",
"object": "payment_intent",
"amount": 12900,
"currency": "gbp",
"status": "succeeded",
"customer": "cus_lab_31bd_redacted",
"metadata": {
"woocommerce_order_id": "1042",
"fixture": "synthetic"
}
}
}
}
}Reconciliation output
One deterministic CSV row recording the mismatch without changing either system.
reconciliation-output.csv
fixture_id,reconciled_at,stripe_payment_intent,stripe_state,woocommerce_order,observed_woocommerce_state,expected_woocommerce_state,amount_minor,currency,webhook_event,delivery_http_status,order_note_found,transaction_id_found,classification,recommended_action
woo-stripe-lab-001,2026-07-12T09:46:38.000Z,pi_lab_7f3a_redacted,succeeded,1042,pending,processing,12900,GBP,payment_intent.succeeded,200,false,false,payment_state_mismatch,manual_confirmation_before_order_edit06 · Positive controls
What still agrees
A useful mismatch report distinguishes aligned identity evidence from the one transition that failed.
- The event is explicitly synthetic, test-mode and marked not for replay.
- PaymentIntent metadata points to the same synthetic WooCommerce order used by the reconciliation row.
- Amount and currency agree across the modeled Stripe and WooCommerce records.
- The Stripe state and event type agree: succeeded and payment_intent.succeeded.
- The reconciliation time is later than the event and webhook attempt timestamps.
- No duplicate Stripe event or second WooCommerce order is introduced into the fixture.
07 · Boundaries
What this lab cannot prove
The fixture demonstrates a reconciliation method. It does not diagnose a reader's store or establish a production root cause.
- This is a synthetic lab fixture, not a client case study, production incident or claim of a successful repair.
- The page does not accept credentials, API keys, webhook secrets, order exports or customer information.
- The fixture does not automatically diagnose a live store or prove why a real order remained pending.
- A real WooCommerce/Stripe setup may use different statuses, plugins, metadata, event types or asynchronous jobs.
- HTTP 200 records delivery acknowledgement only; it does not prove that downstream state mutation completed.
- The expected output is a mismatch classification and manual review boundary, not an automated order edit.
Expected lab outcome
One mismatch row. No automatic order edit.
The deterministic output should classify payment_state_mismatch and recommend manual_confirmation_before_order_edit. That is the end of the lab. It does not claim a repair was performed.
fixture_id=woo-stripe-lab-001
stripe_state=succeeded
woo_state=pending
result=payment_state_mismatch
Use the evidence
Move from the fixture to the right next step
Use the guide for manual checks, the free scanner for read-only comparison, or Payment Rescue when a real customer/order decision is blocked.