Run the Integration Loop

The point of the MCP server is that an agent can not only write an ElasticPay integration but prove it works, end to end, with no human in the middle. The proof hinges on test clocks: instead of waiting a month to see a payment plan renew, the agent advances simulated time and watches the renewal, the payment, and the webhook events appear in seconds.

Once connected, ask your agent to run this loop. Every step is a single tool call from the tool reference.

The loop

Each step is one tool call. The payloads below are ready to paste — replace the …_from_step_N placeholders with the ids returned by earlier steps, and adjust the dates (start_date must be today or later, Australian Eastern Time; the advance target must be after it).

Create a test clock, frozen at a known time. Note the clk_… id in the response.
create_test_clock
```
{
  "frozen_time": "2026-10-01T00:00:00Z",
  "name": "renewal-walkthrough"
}
```
Create a customer on the clock. Customers join a clock at creation; this is what makes their plans follow simulated time.
create_customer
```
{
  "name": "Ada Lovelace",
  "email": "ada@example.com",
  "test_clock": "clk_from_step_1"
}
```
Save a payment method with a fixture token. No widget, no real card: the fixture carries a deterministic outcome.
create_payment_method
```
{
  "fixture_token": "tok_sandbox_visa_succeed",
  "customer_id": "cus_from_step_2",
  "card_name": "Ada Lovelace"
}
```

Take a one-off payment: create an intent, then confirm it with the saved method. Fetch it back with get_payment_intent and expect succeeded.

{
  "amount": 2500,
  "currency": "AUD",
  "customer_id": "cus_from_step_2",
  "payment_method": "pm_from_step_3"
}

{
  "payment_intent_id": "pi_from_step_4",
  "payment_method": "pm_from_step_3"
}

Create and activate a recurring plan funded by the saved method, starting on the clock’s next simulated day.

{
  "customer_id": "cus_from_step_2",
  "name": "Monthly subscription",
  "frequency_type": "monthly",
  "recurring_amount_cents": 4900,
  "start_date": "2026-10-02",
  "until_further_notice": true,
  "payment_instrument_id": "pm_from_step_3"
}

{ "payment_plan_id": "pp_from_step_5" }

Advance the clock past the start date. Advancing is asynchronous: poll get_test_clock until status returns to ready.
advance_test_clock
```
{
  "test_clock_id": "clk_from_step_1",
  "frozen_time": "2026-10-03T00:00:00Z"
}
```
get_test_clock
```
{ "test_clock_id": "clk_from_step_1" }
```
Observe the renewal — the plan has now generated a payment intent under simulated time.
list_plan_payment_intents
```
{
  "payment_plan_id": "pp_from_step_5",
  "limit": 10
}
```
Confirm via events — what a webhook subscriber would have received, newest first, each with delivery status. Webhooks are the source of truth — an agent that checks the event feed is verifying the same signal production code should trust.
list_webhook_events
```
{
  "event_type": "payment_intent.succeeded",
  "limit": 20
}
```

Exercising failure

Swap the fixture in step 3 and rerun: the renewal in step 7 fails instead, and the event feed shows the failure — which is how an agent tests dunning and retry handling without contriving anything.

{
  "fixture_token": "tok_sandbox_visa_decline_insufficient_funds",
  "customer_id": "cus_from_step_2",
  "card_name": "Ada Lovelace"
}

The fixture catalogue covers declines, 3D Secure, and timeouts.

Things agents trip on

Confirmation needs the payment method. confirm_payment_intent requires payment_method even when the intent was created with one.
Advancing is not instant. After advance_test_clock, poll get_test_clock until ready before asserting anything happened.
Plan start dates are Australian. start_date must be today or later in Australian Eastern Time; “tomorrow” is always safe.
Clock limit. Sandbox accounts allow 3 active clocks — delete finished ones with delete_test_clock.