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.
Hold should be a separate payment intent type
Preauthorization reserves payment ability, but should not automatically close order as paid.
Hotels, rentals, clinics, salons and booking-based services often need deposit or amount reservation. But hold differs from successful payment: money may only be blocked, while final capture depends on provider rules, expiration and service result.
Backend should therefore model separate payment intent type: authorization, deposit, capture or direct payment. CRM should show not only paid, but also authorized, capture_pending, captured, voided, expired and manual_review.
- do not treat hold as final payment;
- store service date, amount, currency and customer reference;
- persist provider authorization reference;
- show hold expiration to operator.
Capture, partial capture and void need rules
After service, business should explicitly decide whether to capture full amount, part of it or release the hold.
The main preauthorization risk is mixing reservation, charge and cancellation into one button. If guest did not arrive, service changed or amount is different, backend should check available amount, hold expiration and provider contract rules.
If provider does not support partial capture or card hold, do not promise this UX in article, website or CRM. Use deposit payment or payment link with separate refund rules instead.
- verify provider support before launch;
- do not capture after hold expiration;
- treat partial capture as separate operation;
- void should not delete original audit trail.
CRM and accounting should see full lifecycle
Operator needs history: who created hold, when it expires, what was captured and why it was voided.
Without lifecycle log, support cannot know whether amount is blocked, charged, cancelled or expired. This is sensitive for customer: blocked amount may look like charge even before business performs capture.
A practical model links booking id, payment intent id, provider reference, status transitions, operator notes and reconciliation. Disputed cases then close by facts rather than chat history.
- log actor, reason and timestamp for capture/void;
- connect hold to booking or service order;
- show blocked, captured and released amounts separately;
- reconcile provider report with CRM before daily close.
FAQ
Can preauthorization be used with any vPOS?
No. Preauthorization, capture and void depend on bank, payment provider, contract and operation type. Confirm scenario support before launch.
How is deposit different from hold?
Deposit is usually an actual payment with possible refund, while hold reserves amount until capture or release. CRM should model them as different statuses.
What if hold expires before service delivery?
Do not silently capture. Create a new payment attempt, request payment again or move the record to manual review according to business rules.
