Lovable builds the checkout in a minute. The part that takes three days is finding out what happens when the card is declined, or when the webhook arrives twice.
You can test that from inside Lovable chat. Custom MCP servers are chat connectors, so the agent that wrote the code can also exercise it against an API twin that misbehaves on purpose.
Short answer
Add the MCP server in the connectors dashboard, ask the agent to boot a twin, then have it arm a failure scenario and run the same flow again. Check the end state, not the response.
Add the connector
- Open
https://lovable.dev/dashboard?connectors - Click + at the top right
- Choose MCP server
| Field | Value |
|---|---|
| Server name | FetchSandbox |
| Connection type | Direct connection |
| Server URL | https://fetchsandbox.com/mcp/v1 |
| Authentication | None |
Then Add server. If MCP server is greyed out, a workspace admin has disabled custom servers.
Pick Direct connection — the static IP option is for firewalled servers. This endpoint speaks streamable HTTP, not Server-Sent Events, so take the HTTP route if offered both. Chat connectors are personal to you and never part of your published app.
Boot a twin
Spin up a Stripe test environment and run a payment through it.
You get a sandbox id, a base URL and an API key. Point your app's Stripe base URL at it and your existing code runs unchanged — same paths, same status codes, same error envelope.
Break it on purpose
A checkout that passes on the happy path tells you almost nothing.
What failure scenarios can this sandbox inject?
For Stripe that includes payment_declined, webhook_retries, rate_limited, slow_network, and two almost nobody tests: replayed_old_signed_event and signed_event_with_mutated_body.
Arm webhook_retries and run the checkout again.
Webhooks go to a URL you register, signed the way the provider signs them: HMAC over the raw body, provider header format, real tolerance window. A handler that checks the signature but ignores the timestamp passes manual testing and fails replayed_old_signed_event.
Check the end state
The common wrong conclusion is that the call returned 200, so the code handled it. Ask instead:
- A declined payment must not produce a confirmed order.
- A webhook delivered twice must not charge twice or send two receipts.
Each run returns a share_url — a replayable timeline of every request, response and webhook event. That is what goes in the pull request.
Booting the twin, listing scenarios, arming a failure and running the flow need no account. Start with the failure your users would notice first. For a storefront, that is the duplicate charge.