Test your purchase flow

Before you put Buy buttons on your website, walk the whole funnel yourself. When your app's own developer opens a buy link, the flow runs in walkthrough mode: the same pages your buyers will see, with a test banner, no Stripe calls and no charge — ending with a preview entitlement so you can verify the return into your app end-to-end. It is the supported way to test the integration; it does not exercise payment (see what it does not test).

Run the walkthrough

1. Sign in to usethatapp.com as your developer account (the account that owns the app).
2. Open one of your app's buy links — grab a buy_url from the Pricing API (or build one with purchase_url / purchaseUrl).
3. Walk the pages. You'll see a test mode banner; the payment step is skipped entirely — no Stripe calls, no charge.
4. Finish. Completing the walkthrough sets your developer-preview entitlement for the product you chose, then returns you to your app the same way a buyer would arrive.

https://www.usethatapp.com/buy/{price_id}/?next=https://yourapp.com/welcome

What your app sees

Back in your app, the OIDC return signs you in and get_entitlement reports the previewed product — proof that the return into your app and your feature gates work, without money moving:

{
  "entitled": true,
  "version": "Pro",
  "product_id": "6f0e8f9a-2b1c-4d5e-8f7a-9b0c1d2e3f4a",
  "product_public_id": "prod_9XkKe2QGxN4Ttz1Rw7Ya",
  "status": "preview",
  "is_free": false,
  "period_end": null
}

Gate on product_public_id as usual (see Licensing) — the preview carries the real product_public_id of the product you "bought", so your feature gates light up exactly as they will for a paying customer. The "preview" status tells you it's a developer preview, not a paid license.

What the walkthrough does not test

The payment step is skipped, not simulated. A green walkthrough therefore says nothing about:

• card processing, declines, or 3-D Secure challenges;
• tax calculation and the VAT-inclusive display an EU buyer sees;
• the receipt email and the buyer's manage link;
• the paid status: "active" and a real period_end — the preview reports "preview" and null.

To confirm those, make one real purchase of your cheapest price from a second account that does not own the app, check the receipt and that your app reports status: "active", then request a refund from the buyer's manage link. The platform fee is reversed with the refund.

Test your next URLs

The next param is validated when the link is opened: it must be HTTPS on your app's registered domain (localhost allowed for development). An invalid value shows a "misconfigured link" page — better in front of you now than in front of a buyer mid-purchase. Open every distinct buy link your site renders at least once.

Launch checklist

1. Register your Login URL and redirect URIs on the dashboard's Integration page — the default post-purchase return is the Login URL, and OIDC needs the redirect URIs. See Sign in with UseThatApp.
2. Verify every next URL your site uses is HTTPS on your app's registered domain.
3. Run the walkthrough end-to-end for each product and confirm your app shows entitled: true, status: "preview" with the right product_public_id.
4. Check the readiness list on your app's manage page. A buy link resolves only while your seller account is verified, the app is published, the product is active, and external sales is switched on (it is on by default); otherwise it returns 404.

Next steps

The full selling story is in Sell from your own website; link parameters and buyer behavior are in Purchase links.