Context
A marketplace sells classes, appointments or bundles fulfilled by a third party: the user pays the platform, but value is delivered when the professional completes the service. Finance needs to know what was collected, operations what was consumed, and each provider what is due for settlement — without mixing balances across providers or duplicating “rights” in parallel spreadsheets.
Often customer charges (gateway) and service recognition (app, scheduling, check-in) live in different systems: a partial refund doesn’t map cleanly to the user’s credit, a no-show leaves payment in limbo, and commissions get recalculated by hand at month-end. VaultyCore acts as a service-rights ledger (who can consume what, with whom and until when) and as the source of facts that trigger settlement or dispute.
Common pain points
- User balance vs. provider payout: the customer sees “credits” but the workshop doesn’t know whether they can cash out or confirmation is still pending.
- Opaque bundles: several sessions in one payment; it’s unclear which portion unlocks per completed session.
- Disputes without a single thread: “I didn’t attend / I did” with no sequence of facts finance and support both read the same way.
What Is Modeled in VaultyCore
- Service rights per purchase: credits tied to provider, session type or package, with time or usage limits.
- Lifecycle: issuance on payment, partial or full consumption, cancellation, re-booking and extension — each event as a verifiable fact.
- Settlement conditions spelled out (e.g. “released when marked complete by provider and no open dispute”).
- Vault separation for brands, cities or business lines sharing one platform.
Customer charge vs. provider settlement
VaultyCore does not replace your gateway or payout ERP: it structures the rights the marketplace and provider apps must honor. The healthy flow is: payment or agreement confirmed → service rights issued in the ledger → fulfillment (or dispute) recorded as facts → finance reconciles commissions and third-party payouts against that chain, not loose estimates.
Running a services marketplace and need auditable credits per provider? We’ll show you how VaultyCore sits between payments, scheduling and settlement.
Typical Operational Flow
- Checkout or B2B contract confirms payment and terms (commission, validity window, assigned or eligible provider).
- VaultyCore issues the corresponding rights (passes, credits or sessions) in the verifiable ledger.
- Scheduling or operations consume or release rights when the service completes or cancellation policy applies.
- Finance and the provider review the chain of facts for payouts, commissions and disputes without rebuilding the case across three systems.
Multi-provider and multi-city
The same stack often serves many providers and regions with different commission and currency rules. One rights model per vault keeps the user’s “global” credit from mixing with a specific shop’s settleable balance.
Outcome
Less friction between what the customer believes they bought and what the provider can execute; closes with fewer manual adjustments and a clear audit story: which right was issued, who consumed it and when it became payable.
Complex split payments, dispute rules and chained re-bookings can be added as policies on top of this ledger without erasing rights history.