# Payment Infrastructure 2026 — Vexlora v1.0.0

Vexlora models payments as a shared **money-movement control plane**, not as one checkout form or one finance ledger. The same provider adapters can support several business domains, but each money lane keeps its own authorization, risk, accounting and settlement lifecycle.

## Four money lanes

1. **Pay-in** — customer, patient, student, tenant or subscriber pays a business obligation.
2. **Marketplace split** — a marketplace allocates captured funds among seller balances, platform fees and reserves.
3. **Pay-out** — approved seller earnings, employee payroll, supplier invoices, contractors, drivers, commissions or other liabilities are released to a verified destination.
4. **Adjustments** — refunds, reversals, disputes, chargebacks, reserve releases and corrections reference the original money movement and create their own evidence/accounting trail.

These lanes can share a provider connection, but they are deliberately not treated as the same transaction type.

## Why an international product supports multiple payment providers

A global admin product may need several provider adapters because no single provider has identical coverage for every country, merchant entity, currency, local payment method, marketplace model, payout destination, risk policy or availability requirement. A buyer should enable only the providers relevant to its legal entities and markets.

Provider routing can therefore be based on:

- merchant/acquirer region and supported customer country,
- currency and local payment-method availability,
- recurring/tokenization capability,
- marketplace connected-account and split-payment capability,
- payout-country and payout-method support,
- authorization performance, cost and risk posture,
- outage/capacity fallback rules that have been tested in advance.

Vexlora keeps this provider-neutral. Stripe, PayPal, Adyen, Checkout.com, Razorpay, Mollie and a custom adapter are sample capability profiles, not bundled live financial services.

## Customer card collection

The admin template must **not** collect or store raw card numbers or CVV values in ordinary React form state. In production, the buyer should use a provider-hosted checkout, hosted fields/elements, tokenization SDK or equivalent PCI-scoped collection surface. Vexlora stores or displays only safe references such as provider customer IDs, payment-method tokens/references, masked brand/last-four information and status.

If a reusable payment method is saved, the production integration must also implement the provider's required customer consent, authentication and mandate rules.

## Bank transfer vs payout bank destination

Two different workflows are intentionally separated:

### Customer bank transfer

A customer may receive provider-generated beneficiary/virtual-account instructions and send money to that destination. The browser redirect or user claim is not authoritative; provider/backend events confirm that funds were received and reconciled.

### Seller, employee or vendor payout destination

For outgoing payouts, **provider-hosted onboarding or bank-account collection is preferred**. It reduces the amount of sensitive financial data the buyer must handle directly. Vexlora keeps the provider account/destination reference plus masked metadata.

A manual bank form is shown only as an implementation blueprint for buyers whose provider or banking partner requires it. Production values must be submitted to the buyer's secure backend/provider adapter and must not be persisted in browser storage or bundled sample data. Country-specific fields can include account holder, bank/branch code, IBAN, routing number, account number, SWIFT/BIC and payout currency depending on the destination country.

## PayPal and receiving-account services

PayPal can represent different capabilities: customer checkout, merchant/partner onboarding and outgoing payouts. A production integration uses provider authorization/tokens—not a seller's PayPal password.

Where supported, services such as Wise, Payoneer or Revolut can expose receiving-bank coordinates. In that case Vexlora treats the coordinates as a **bank-transfer destination**, subject to provider/country eligibility and verification, rather than pretending each service is a universal payment gateway.

## Marketplace connected accounts, balances, splits and reserves

A marketplace seller business record is not itself a payout account. A production marketplace typically needs:

`Seller/vendor → verified connected account/sub-entity → capabilities → balance allocation → reserve/hold → available balance → verified payout destination → payout schedule`

The Payment Core therefore separates:

- eCommerce seller/catalog management,
- provider connected account / KYC-KYB readiness,
- transaction split or transfer profile,
- platform fee, seller allocation and reserve,
- payout destination and payout schedule,
- Finance settlement/reconciliation.

For multi-seller carts, the platform/backend must keep a durable allocation ledger. If the customer is refunded, the refund does not imply that every earlier seller transfer or platform fee will automatically be reversed correctly; the integration must apply the provider-specific reversal policy and reconcile the resulting balances.

## Refund, reversal and dispute lifecycle

Vexlora preserves the original payment and business document. A typical refund path is:

`Original payment → refund authorization → provider refund/reversal → marketplace allocation reversal when required → fee/reserve adjustment → provider event → domain update → Finance credit/reconciliation`

A **credit note** is an accounting document and is not the same thing as the provider moving cash. A **dispute/chargeback** is a provider/card-network claim with evidence deadlines and can create reserve, fee and loss consequences.

## API, webhooks and idempotency

Production provider actions must execute through buyer-owned server code. Vexlora's frontend stores references/configuration metadata only.

Required backend responsibilities include:

- secret/API-key storage in a vault or server environment,
- creating checkout/payment/setup/onboarding sessions,
- verifying webhook/event signatures,
- deduplicating provider event IDs,
- applying idempotency keys to retryable money-changing requests,
- server-side authorization and amount/currency validation,
- persisting provider object IDs and internal ledger references,
- reconciling provider balance/settlement reports with Finance,
- handling asynchronous success/failure instead of trusting only a browser redirect.

## Payment ownership across all 19 dashboards

The Payment Core maps every dashboard without forcing every suite to become a payment screen.

- **Direct collection/refund:** eCommerce, SaaS, CRM, Hospital, Education, Real Estate, Energy, Logistics.
- **Outgoing payout/payable handoff:** Projects, ERP, HR, Construction, Logistics, Real Estate.
- **Accounting/reconciliation:** Finance is the financial system of record for settlement, payables/receivables and ledger impact.
- **Indirect cost/payable context:** Inventory and Marketing create obligations or cost context that hand off through ERP/Finance/AP before payout.
- **Observe/advise:** Executive, Analytics, AI and Support consume payment outcomes or initiate governed support/refund workflows without becoming the ledger.

Hospital staff salary is therefore an **HR payroll → Finance funding → Payment payout** flow; Hospital billing remains patient/insurance collection. The same ownership principle prevents duplicate payroll or finance logic inside industry dashboards.

## Frontend template boundary

Vexlora is an admin-template product. Sample buttons can create local UI state and show the intended request/evidence flow, but the source does not ship usable gateway credentials, move real money, store raw card/CVV data or become a regulated financial ledger. Buyers connect their own backend, provider accounts, compliance process and accounting infrastructure through the documented adapter boundaries.