Key topics
Related public pages
If you need the product, API or operations page rather than only the article, start with these VPOS.am sections.
Payment request should know booking context
Amount without date, specialist and service id does not help support when appointment is moved or cancelled.
Clinics, salons and service teams often take prepayment, deposit or full payment before visit. If payment link is not connected with booking context, operator cannot easily know which service was paid and whether appointment can be moved.
Backend should store service id, appointment time, branch, specialist, amount, currency, expiration and CRM reference. After verified payment, appointment gets controlled status instead of manual chat note.
- connect payment request with appointment id;
- fix branch, specialist and time slot;
- do not store medical details in payment event;
- show pending/paid/expired/manual review in CRM.
No-show, transfer and cancellation should be rules
Deposit works only when it is clear what happens after late arrival, reschedule or cancellation.
Payment integration should not decide medical or service policy, but it should technically support it. For example, if customer cancels before deadline, system shows available refund path; if appointment is moved, payment context remains connected.
Cancellation, refund and no-show should not be merged into one status. They are different events with different access rights, deadlines and audit trail.
- store cancellation window and policy version;
- appointment transfer should not lose payment reference;
- refund needs separate reason and actor;
- manual exception should enter audit log.
Privacy and reconciliation matter more than extra data
Payment backend usually does not need medical details; it needs ids, amounts, statuses and audit trail.
For clinics, data minimization in payment layer is especially important. Payment backend should see appointment identifiers, amount, currency, provider reference and status, but should not store unnecessary medical or sensitive data.
Daily reconciliation compares provider payments, appointment statuses, CRM records and refunds. Team can see paid appointments, cancellations, no-show cases and exceptions without manually assembling spreadsheets.
- minimize personal data in payment log;
- reconcile paid appointments with provider report;
- show refunds and no-show separately;
- restrict access to sensitive CRM context.
FAQ
Can service details be stored in payment backend?
Prefer storing only necessary ids, amount, currency and status. Service details and sensitive context should remain in CRM/booking system with restricted access.
What if appointment moves after payment?
Keep payment reference and connect it with new appointment date through controlled status change. Original payment history should not disappear.
How should no-show be handled?
Through predefined rules: cancellation window, deposit policy, manual review and audit trail. Payment layer should support the rule, not make the business decision itself.
