Take payments in your app

A Maker app is static, which normally rules out selling anything: a static app has no server, so there is nothing to check whether a visitor paid. Payments closes that gap without giving your app a backend and without putting any key in its code.

The shape is deliberately simple. You sell through your own Stripe account, so the money goes straight to you. Onplana never touches the funds, never takes a cut of them, and never holds a credential that could move them.

Note

The one line worth remembering: the only Stripe credential Onplana ever stores is a webhook signing secret, which lets us verify messages from Stripe. It cannot move money, issue refunds, or read your customers. Your secret API key stays in Stripe, where it belongs.

What you need first

• A Stripe account (free to create).
• A Payment Link for the thing you are selling, created in your Stripe dashboard. A Payment Link is just a URL, which is why your app needs no key: it simply links to it.

Connect Stripe to your app

Steps

1. In Build, open the Payments panel on the bottom strip.
2. Choose Test mode first. Everything below works identically with Stripe’s test cards, and you can switch to live when you are happy.
3. Onplana gives you a webhook address unique to this app. Copy it.
4. In Stripe, go to Developers → Webhooks → Add endpoint, paste that address, and select the events the panel lists.
5. Stripe then shows you a signing secret starting whsec_. Paste it back into the Payments panel.
6. The panel waits for your first event and turns green the moment Stripe reaches us. Use Send test event in Stripe if you do not want to make a test purchase yet.

That last step matters more than it looks: it is the difference between believing the setup worked and knowing it did. Nothing is marked connected until a real, signature-verified message arrives from Stripe.

Caution

Never paste a Stripe secret key (sk_live_…, sk_test_…) into your app’s code. You do not need one, and a published app is public, so anyone could read it. Onplana refuses to publish an app containing a live secret key, and the build agent will decline if you ask it to add one.

Choose what unlocks the app

A Stripe webhook belongs to your whole account, not to one product. So if you sell more than one thing, Onplana needs to know which purchase unlocks this app, otherwise buying anything at all from you would unlock it.

You do not have to hunt for product IDs. Make a test purchase (or send a test event), and the Payments panel shows what it received, for example “we received 49.00 USD via this link”, with a This unlocks my app button. One click and you are done.

If the app you are selling is the only thing in your Stripe account, there is an allow any payment option instead. It is a deliberate choice with a warning, not the default.

Selling a file

If you are selling a PDF, a template, or a zip, add it in the Files buyers get section of the same panel.

This is the part that makes the paywall real. The file is stored privately, never inside your app’s code and never at a public address. The only way to it is a download link that checks the buyer’s unlock on every single request , which means a refund closes access again, rather than the buyer keeping a link forever.

Caution

If you skip this and simply put the file in your app instead, anyone can find it by viewing the page source, whether or not they paid. A published app is public bytes. Uploading the file here is what actually keeps it back.

What your buyers see

• They click Buy, which takes them to Stripe’s checkout.
• After paying, they land back on your app and it unlocks immediately.
• If they come back on a different device, or clear their browser, they use Already bought? Restore access and enter the email they paid with. Onplana emails them a link that unlocks it again.

For their privacy, that restore screen always says the same thing, whether or not that address ever bought anything, so it can never be used to find out who your customers are.

Keeping an eye on sales

Once payments are set up, the Payments panel shows how it is going without you having to open Stripe:

• Unlocks this week, and how much came in, listed per currency. Amounts are never added across currencies, because a total of euros plus dollars is not a real number in either.
• If nothing sold this week, you see the running total instead, so a quiet week does not look like a broken app.
• The figures come from access that is currently granted, so a refund removes that sale from the total rather than leaving it there forever.
• Unlocks you gave away free, using a 100%-off promotion code in Stripe, still count as unlocks. They simply add nothing to the money line.

If payments stop unlocking

The most common way this breaks is that the signing secret changed in Stripe and the new one was never pasted back into Onplana. Every payment then arrives with a signature we cannot verify, so buyers pay and get nothing.

Onplana watches for this. After a few events in a row that fail to verify, we email you and show a warning in the Payments panel. This is the one payment event we do email you about, because Stripe cannot tell you about it: from Stripe’s side the charge succeeded.

To fix it, open the Payments panel, choose Replace signing secret, and paste the current one from your Stripe webhook endpoint. The warning clears straight away. If the new secret is also wrong, the warning comes back on the next payment, so it never tells you things are fine when they are not.

About the people who paid while it was broken. We could not verify those events, so we did not record them. Stripe keeps retrying a failed webhook for about three days, which means that if you fix the secret within that window, those payments arrive on their own and unlock as normal, with nothing for you or your buyer to do.

If more time than that has passed, the payments are not lost, they are just not coming back by themselves:

1. Fix the signing secret first, so new events work.
2. In your Stripe dashboard, open the webhook endpoint, find the failed events, and use Resend. Each one then unlocks the buyer who paid for it.
3. If Stripe disabled the endpoint after repeated failures, re-enable it there before resending.

Your buyers can also use Already bought? Restore access once their payment has been processed, so a resend fixes them even if they gave up and left.

Refunds, disputes, and part-refunds

• A full refund revokes access on the buyer’s next visit.
• A partial refund (say a small goodwill credit) does not revoke access.
• A chargeback revokes access while it is open; if you win the dispute, access comes back automatically.
• If someone buys twice and you refund one of those purchases, they keep access, because the other one still stands.

Turning payments off

Disable in the Payments panel stops new payments being processed. Buyers who already paid keep their access, and re-enabling later reuses the same webhook address, so you do not have to reconfigure Stripe. Disabling also clears any “payments are not unlocking” warning, since nothing is being processed to fail.

Good to know

• Available on every plan, including Free.
• Onplana takes no cut of your sales. Stripe’s own fees apply as normal.
• You are the merchant. Refunds, disputes, tax, and customer support are between you and your buyer, handled in your Stripe dashboard.
• Onplana emails you nothing for each sale, because Stripe already does. Sales show up in your notifications and in the Payments panel. The one thing we do email about is payments failing to unlock, since Stripe cannot tell you that.
• Payments are one-time today. Subscriptions are not supported yet.
• Prices live in your Stripe Payment Link, not in the app, so change them in Stripe and the app follows.

Related

• Control who can use your published app, the access mode decides whether this feature can be per-person or stays anonymous.
• Collect form submissions, gather details from the same visitors.
• Accept file uploads in your app, take files alongside payments.