Paying for an order
Card, saved card and wallets — whichever you offer.
Paying happens where the choosing happened — with a saved card in two taps, without being thrown onto someone else's page.
Payment does not throw a person out of the app or make them type the card in again every time. The receipt arrives by itself, and if something went wrong the refund is visible in the history rather than argued about in chat.
Payment is attached to what already exists: an order, a booking or a pass.
Card, saved card and wallets — whichever you offer.
Partial or full, by the rules you set.
A package is paid for once and then drawn down visit by visit.
Full and partial, reflected in the person's history.
Fiscalisation runs automatically and the receipt goes to the customer.
What, when and how much — in the profile and in your panel.
The money goes through your own contract with a payment provider; the commission is theirs, not ours.
Your provider and your legal entity — the app only passes the payment along.
Where payment is required, where prepayment applies, where paying on collection is fine.
The receipt is issued automatically and reaches the customer by email or in the app.
Tell us about your customer scenario — we'll suggest the right modules and the scope of the first release.
Discuss an appYour payment provider, under your contract with them. We are not part of the settlement and take no commission.
Yes, full or partial. It is the simplest way to cut no-shows where they are expensive.
Issued automatically on payment and sent to the customer. The till is connected together with the acquirer.
Full and partial refunds are made from the panel, and the customer sees them in their payment history.