Online membership payments in the app: how to set them up

A client decides to renew their membership pass on a Sunday evening — and runs straight into "come in tomorrow and see the front desk". Online payment removes that pause: the client buys a pass and arranges a paid freeze right there in the app, the money goes through your company's own card processing, and the pass appears in their account as soon as the payment is confirmed. Here's how it works, what the client and the front desk see, how to connect your own payment gateway, and why unpaid purchases never reach your revenue.

What online membership payments are and who needs them

Online payment lets a client pay for a membership pass or a freeze inside the app, by card, with no trip to the desk and no transfer "to the manager's personal account". For a studio that's two things at once: sales during the hours when nobody is working, and less manual work — no taking payment, issuing the pass and writing it into a notebook.

It shows up most where the pass is the main product: gyms and yoga, dance and martial arts, children's clubs, courses, group studios. Renewals happen there regularly, and almost always at an awkward moment — in the evening, from home, the day before the pass runs out. Online payment doesn't yet cover one-off visits and bookings with a specialist: those are still paid for on the day.

How it works: your own acquiring, not a middleman

Every company connects its own online card acquiring — the contract is signed directly with the payment provider and the money lands in the company's account under its own agreement. SetNow takes no part in the settlement and holds no client money: the app only creates a payment at the gateway and listens for its confirmation. bePaid is supported today; the architecture is built so other providers can be added without changes in the apps.

Card details are entered by the client on the payment gateway's page, not in the app — neither SetNow nor the company's employees ever see them. The gateway access keys are entered by the company itself in its own dashboard; the secret key is stored encrypted and is never shown back to anyone, support included. You can test the connection before going live in test mode — payments are created with a test flag and no money moves.

What the client sees

Buying happens in the client app — SetNow Client, or your company's branded app. It's a short path:

• In the membership passes section the client opens the one they want and taps "Buy". The section only appears for companies that have connected and switched on payments — other clients simply don't have it.
• A secure payment gateway page opens where the client enters their card details and, if required, confirms with their bank.
• After paying, the app returns the client to a result screen and waits for confirmation from the gateway — usually a few seconds.
• The pass appears in the client's account, and its expiry runs from the payment date rather than from the moment the purchase was started.
• If confirmation arrives later — say the client has already closed the app — a "Payment successful" push arrives and the pass is waiting in their account.

An important detail: the pass is issued only once the gateway confirms, not because the client came back to the app. You can return from a browser without having paid — and the system doesn't respond to that by handing over the goods.

If the client changes their mind or closes the payment page

The classic situation: the client opens the payment page, looks at the amount and goes back. The app tells the difference between a return via the gateway's redirect and closing the page by hand: in the second case it checks the status quickly and shows "Payment not completed" instead of waiting for a confirmation forever. From there two actions are available — "Back to payment" if the client has decided to pay after all, and "Pay again" if the previous attempt is no longer usable.

The difference between the buttons isn't cosmetic. A gateway payment page is single-use: after a bank declines it, you can't retry on that page, you need a new payment — which is exactly what "Pay again" creates, rechecking the terms and the price from scratch. An abandoned but still-live payment simply opens again. Incomplete payments close automatically after an hour, and no pass is issued for them, naturally.

What the front desk sees

Online sales don't live a separate life: they land in the same place as passes issued in person. The web dashboard and the employee app both have an "Online payments" section, where every payment is visible:

• Who paid, for what and how much: the client with their phone number, the pass name or a freeze with its number of days, the amount and the date.
• Payment status: awaiting payment, paid, failed, expired, cancelled. The list filters by status and searches by client name or phone number — an employee has no need to know the gateway's transaction number.
• A separate "needs resolving" flag — the rare case where the gateway has the money but the purchase couldn't be issued. Such a payment doesn't get lost: it's highlighted both in the list and in a banner at the top.
• The purchased pass itself appears on the client's record — with the same terms, limits and expiry as one issued by hand.

None of this gets in the way of selling in person: the front desk still issues passes paid for on the spot, and arranges freezes from the client's record. Online payment is an extra channel, not a replacement for the till.

Paid membership pass freezes

The second payment scenario is a freeze. The client picks the length in the app and the system works out the price from the pass's own rules: the price per day and the day limit are set in its terms, so there's no "negotiating" a different amount on the client's side.

If freezing is free at your studio, the payment gateway isn't involved at all — the freeze is arranged immediately. A paid one goes the same route as a purchase and is only arranged once the payment is confirmed.

How to connect it: five steps

Setup is entirely on the company's side — no support tickets and no involvement from SetNow:

• Sign a contract with a payment provider and get access to their dashboard. That's a separate service from a bank or acquiring provider, with its own rates and document checks.
• Open the "Online payments" section in your SetNow dashboard — it's available to the owner and to administrators with the relevant access.
• Enter the shop ID and secret key from the provider's dashboard. Leave test mode switched on.
• Make a test payment from the client app using the provider's test card: check that the pass appears in the client's account and that the payment shows in "Online payments".
• Switch test mode off and turn on "Accept payments". From that moment the buy buttons are visible to clients.

The reverse works too: turning payments off removes buying from the app. But payments started before you switched it off are seen through to the end — if the money was taken, the client gets their pass. Otherwise the switch would be a way of taking money without handing over the goods.

Where the money goes and when it counts as revenue

The money goes into the company's account through its own acquiring: settlement times and fees are a matter for your contract with the provider, and SetNow neither influences them nor withholds anything. Refunds to a client are also made in the provider's dashboard — there are no automatic refunds in the app; the pass itself is then revoked by the front desk on the client's record.

In reports an online sale counts exactly when the payment is confirmed. A purchase that was started and abandoned creates no pass, and therefore reaches neither revenue, nor statistics, nor payroll. Online payment didn't require any change to the reporting rules: they count passes issued, and passes are only issued once payment has gone through.

Frequent questions

• The client paid and closed the app straight away — will the pass be issued? Yes. The outcome is decided by the gateway's confirmation, not by whether the client waited for the result screen; a push announces the pass.
• Can we take online payment for a one-off booking? Not yet: online payment works for membership passes and paid freezes, while a visit is paid for on the day.
• Do we need a fiscal till, and who issues the receipt? SetNow doesn't produce receipts. Everything to do with fiscal receipts is settled on the side of your provider and your till solution — check it when you sign the contract.
• Does payment work in a company's branded app? Yes, the gateway is connected for a company rather than for a particular build: the same app behaves differently for different companies depending on their settings.
• What happens if we have no card acquiring at all? Nothing breaks: clients simply won't see buying in the app, and the front desk issues passes exactly as before.
• Does SetNow see card details? No. Payment happens on the payment gateway's side and the app receives only the payment status.

Where to start

If you already have card acquiring, connecting it takes an evening: keys in the settings, a test payment, switch acceptance on. If you don't, start with a conversation with a provider about rates, and go on selling passes as usual in the meantime — the app works perfectly well without online payment. A month after launching, look in "Online payments" to see what time of day purchases arrive: it's usually evenings and weekends — the hours that used to be lost entirely.

In SetNow, online payment runs on the company's own card acquiring: the client buys a membership pass or a paid freeze in the app, the pass is issued only after the payment is confirmed, payments are visible in the dashboard and in the employee app, and revenue counts only what has actually been paid. It's connected in the "Online payments" section and off by default — for anyone who doesn't need online payment, nothing changes.