Improvement·Sun Sep 13·
Paid appointment recovery
When a client pays online for an appointment on the Web or embedded booking page, the page now keeps an encrypted record of that exact payment attempt before it starts. Refreshing the page, a lost connection or a bank approval redirect offers "Finish payment" for the same attempt instead of starting a second one. Choosing another time after an unclear result first checks with the server that nothi
When a client pays online for an appointment on the Web or embedded booking page, the page now keeps an encrypted record of that exact payment attempt before it starts. Refreshing the page, a lost connection or a bank approval redirect offers "Finish payment" for the same attempt instead of starting a second one. Choosing another time after an unclear result first checks with the server that nothing was charged. If the page cannot tell whether a payment went through, it says so and offers "Check again" rather than claiming success. Signing in during checkout continues the same payment. If the browser session is replaced or ends, the page asks for a refresh before anything else starts. No notes, card details or sign-in tokens are stored as readable browser text. This is not deployed. Business, Consumer and Branded app parity for this recovery, displayed-price agreement and grouped visits are still being completed. Recovery does not mean a confirmation message was sent, and no Nailtech settings or client communications were changed by this work.
Next update
Appointment payment recovery groundwork
Paid appointment adapters preserve the provider and price held by an existing checkout instead of rereading current venue policy after preparation. They accept an unnamed any-available request and keep retries on the same payment operation. This is local source work, not a live feature announcement.