Lovable Built a Pet Store. Checkout Hit a Paddle Twin.

The prompt was one sentence: build a pet store on Paddle, send mail with Resend, and verify both end to end like production on FetchSandbox twins.

Lovable did not open a Paddle dashboard. It called validate_integration with resend and paddle. The workspace was not on a paid Lovable plan, so built-in Paddle was blocked. Passport offered Use test twins only. That is the path this store actually took.

The storefront is live: pet-payment-playground.lovable.app — Pawsome Pantry, Wild Salmon Kibble at $42.

Short answer

1. Prompt Lovable for its stack, name Paddle + Resend, and say twins — not live keys.
2. Add FetchSandbox as a custom MCP connector: https://fetchsandbox.com/mcp/v1, Bearer from fetchsandbox.com/keys, not None.
3. When Passport says Paddle needs a paid plan, pick Use test twins only. Do not paste twin secrets into chat. Put PADDLE_API_KEY, RESEND_API_KEY, and PADDLE_WEBHOOK_SECRET in Lovable's secrets form from the secure handoff.
4. validate_integration scores your published origin. The Paddle→Resend receipt_recovery_v1 suite on this store came back Inconclusive (6 passed, 2 not checked). verify_behavior on webhook_signature_false_negative is a reference handler on the twin — it is not the pet store's webhook.

This workspace chose temporary test providers instead of configuring live payment services. The result below records what that choice verified—and what it did not.

Passport told the truth twice

Paddle sells digital products and services. Kibble that ships is a physical good. Passport said Shopify would fit a real catalog. For this test, the job was checkout + email, not freight.

Then: Paddle payments need a paid Lovable plan. Options were upgrade, Stripe with your own keys, or twins.

Use test twins only is the honest fork when you want to test the integration without configuring live payment credentials.

What shipped

The preview is a real catalog: dogs, cats, small pets, add to cart. Publish produced Pawsome Pantry.

The agent asked for three secret names, not values in the thread:

Copy those from the handoff page into the form. Do not paste them into Agent chat, a source file, or a screenshot you intend to publish.

Twins are hosts. If the Edge Function still calls api.paddle.com, the connector is a spectator.

The verify_behavior receipt

After publish, Lovable called verify_behavior:

That pattern is a reference Paddle webhook handler, not the published store’s own webhook. The bug is HMAC over a re-serialized JSON body instead of the raw bytes Paddle signed — every valid notification looks invalid. Buggy returns 401 on a genuine Paddle-Signature. Fixed verifies raw bytes and returns 200.

The tool call shown here targets that reference failure class. The screenshot records the call, not a complete result. It does not prove Pawsome Pantry's route.

The receipt suite: 6 passed, not green

The store then ran Paddle → Resend receipt_recovery_v1 against the published app (pawsome-pantry-v1.1 declared). Headline: Receipt verification incomplete. Inconclusive.

6 passed · 0 failed · 2 not checked. View the recorded receipt. Run vr_6bdaa4e649ea483a83593120987cdc60. Window 2026-10-02 21:13–21:16 UTC. Webhook deliveries 53/53. Checkpoints 33/33.

R5 was unmeasured because the run did not see a failed app webhook callback retry while Resend's already-accepted send was still withheld. R7: the declared transient fault was not observed. The page stamps controlled_twin_receipt_behavior_only, app_version_is_declared_not_attested, and no_production_readiness_claim.

That is the useful artifact. Happy-path receipts held. Two recovery checks lacked the evidence needed for a decision, so the suite refused to call the store proven. Do not treat 6/8 as launch.

For a follow-up, ask the builder agent to inspect the saved request timeline for R5 and R7, correct the identified app or test setup issue, and execute a fresh app-level receipt suite. Provider acceptance is not proof of real inbox delivery.

The agent also wrote the limit out loud: Paddle is not really connected yet. The store talks to FetchSandbox's test copy. A physical catalog would likely need Shopify for live selling.

What this is not

• Not live Paddle or Resend. No paid Lovable Paddle plan was used.
• Not Gmail. Twin send ≠ inbox.
• Not production-ready. receipt_recovery_v1 was Inconclusive; the receipt itself says no_production_readiness_claim.
• Not proof that the pet store's webhook accepts raw-body signatures — that is the reference verify_behavior run.
• Not an intercept. The app must call the twin hosts.
• Not a dunk on Lovable. Passport named the plan gate and the physical-goods limit correctly.

Gym walkthrough (same providers, different app): build then verify. AI app builder testing setup.

Questions about this Pawsome Pantry run

Did checkout use live Paddle?

No. The workspace was not on Lovable's paid Paddle plan. Passport selected test twins. The recorded run used temporary test providers. It does not establish the store’s current configuration; those credentials expire and must be removed after testing.

Does verify_behavior mean the pet store's webhook works?

No. webhook_signature_false_negative runs FetchSandbox's reference handlers (buggy vs fixed) on twin 67bb0f7b5f. Your Edge Function is a different file. Use validate_integration against the published origin for that.

Is 6 of 8 receipt checks a pass?

No. The suite returned Inconclusive because R5 and R7 were not checked. Zero failures is not the same as every recovery branch running. The receipt stamps no_production_readiness_claim.

Why not just upgrade and use 4242?

A provider’s test checkout is a different scope from the application’s combined payment-to-email recovery behavior. This run used temporary providers to exercise that combined path.

Can Paddle sell bags of kibble?

Not as physical goods. Passport said so. The test providers let this demo exercise payment + email behavior without selling physical goods through live Paddle.