# Payment Core — v1.0.0

Vexlora Payment Core is the provider-neutral money-movement infrastructure shared by the platform. It separates checkout/payment execution from Finance accounting and separates marketplace allocation and payouts from customer pay-in.

## Core routes

- `/payments` — Payment Core overview and all-19-dashboard ownership map
- `/payments/transactions` — central payment attempts/register
- `/payments/methods` — payment-method and market eligibility
- `/payments/providers` — provider capabilities, credential references and webhook posture
- `/payments/accounts` — payees and payout destinations
- `/payments/marketplace` — connected accounts, balances, splits and reserves
- `/payments/checkout` — checkout/payment-link configuration
- `/payments/routing` — provider priority, fallback and recovery rules
- `/payments/refunds-disputes` — refunds, reversals, disputes and evidence
- `/payments/payout-routing` — payroll, seller, supplier, contractor and commission payout rails
- `/payments/domain-flows` — deep cross-domain architecture view

## Ownership

**Payment Core owns:** provider adapters, payment attempts, routing, checkout execution state, connected financial accounts, payout destinations, marketplace movement, payout rails, refund/dispute execution state and provider-event health.

**Finance owns:** receivables/payables accounting, treasury/funding, settlement reconciliation, credit notes, fees, reserves and ledger impact.

**Business domains own:** the order, invoice, subscription, payroll, patient bill, fee, rent, project/vendor obligation or other business document that explains why money should move.

## Four-lane model

`Pay-in → Marketplace split/reserve → Pay-out → Adjustments`

Not every transaction traverses every lane. Ordinary SaaS checkout may only use pay-in; marketplace commerce can use pay-in + split + payout; a payroll run uses payout; a return/refund uses adjustments against the original payment/allocation.

## Secure integration boundary

Vexlora is frontend-only. Raw card/CVV collection, bank-account secrets, usable API credentials, webhook signature verification, idempotency, KYC/KYB, server-side amount validation and actual money movement belong to the buyer's provider/backend integration. Provider-hosted or tokenized collection is preferred wherever available.

See [`PAYMENT_INFRASTRUCTURE_2026.md`](./PAYMENT_INFRASTRUCTURE_2026.md) for the international marketplace, card/bank, payout, refund and API architecture.