Payment-method isolation

VSL does not rely on generic amount-only matching across payment methods. Card, bank-transfer and crypto records are separated so that a card event cannot legitimately settle a bank-transfer record, and a bank-transfer event cannot legitimately settle a card record. Provider reference, method, amount, currency and ownership/context are matched as required by the rail.

What VSL does not collect as a substitute for provider checkout

VSL does not ask users to send card PINs, CVVs, banking passwords, private keys or one-time bank authentication secrets through VSL chat, AI prompts or ordinary order notes. Sensitive payment authentication belongs in the provider/bank/wallet flow designed for it.

VSL's financial layer includes seller-ledger, debt, reserve/risk, reconciliation and payout-guard components. The exact checks applied depend on the payment rail and feature path, but the control model is to prevent a payout from being triggered simply because a UI says “paid”.

• Fincra: VSL's active payment path checks provider success together with the VSL/POS reference and relevant account, amount and external provider-reference evidence before applying the result. Fincra documents HMAC-SHA512 webhook validation and transaction verification.
• NOWPayments: the crypto path uses provider payment state and confirmation logic; a created payment or partial/unconfirmed crypto observation is not equivalent to a completed seller settlement.
• Busha: the integration includes dedicated webhook-signature, sensitive-data, consent and idempotency components, and provider responses are sanitised before diagnostic logging.
• Replay/duplicate defence: VSL's idempotency controls make repeated provider events or retried internal work converge on the same payment/payout result instead of creating a second financial effect.
• Ambiguity handling: VSL leaves an event unresolved and routes it to reconciliation or review when it cannot be matched safely; VSL does not guess the event onto a seller, invoice or payment request.

VSL does not publicly expose this evidence. Sensitive financial, identity, risk and provider data is limited to the workflow, review or legal purpose for which it is required.

Core monitoring checks include the VSL/provider reference, expected amount and currency, payment method, provider status, webhook/callback integrity, duplicate or replay state, ownership/KYC status where applicable, payout state and reconciliation evidence. Refunds, reversals, chargebacks, disputes and delivery evidence remain connected to the same transaction history.

When a transaction needs more review, VSL can request supporting information, restrict or pause its own payment/payout instruction, preserve relevant records, route the issue to the applicable provider or limit the account capability. Provider-side custody remains with Fincra, NOWPayments or Busha; VSL's monitoring controls the VSL orchestration and software layer.

Read the Fraud Prevention, Transaction Monitoring & Lawful Requests framework →

Depending on the country, user type and payment or payout feature, KYC/KYB can include legal name, date of birth, residential/business address, phone/email, business registration information, beneficial ownership information, national identity data, identity documents and selfie/liveness evidence. Higher-risk or provider-triggered review can also require source-of-funds or source-of-wealth information.

For enabled Busha settlement workflows, VSL's integration model records explicit consent before sharing the identity and payout information needed for provider onboarding. Terms/consent timestamps and provider references are recorded rather than assuming acceptance without a user action.

• Nigeria: VSL's enabled local-settlement architecture can route eligible BTC/USDT conversion through Busha to an NGN bank destination, subject to provider KYC, ownership and product availability.
• Kenya: the enabled architecture can route eligible BTC/USDT conversion to a permitted KES/M-Pesa destination, subject to provider KYC, ownership and product availability.
• Other VSL regions: availability of crypto transactions or a provider account does not automatically mean that the same local fiat payout path is available. VSL checks the specific rail before presenting it as enabled.

• A dispute can connect the invoice/order, payment request, provider reference, conversations, seller/customer acknowledgement and available delivery or handoff evidence.
• Where the financial layer applies, an unresolved dispute, reversal or chargeback can place the related payout into a review/hold path and preserve an evidence envelope for investigation.
• If a refund or chargeback creates a seller liability after payout, the seller-ledger/debt model can represent that obligation and apply permitted future-earnings recovery instead of silently changing old provider records.
• Users remain responsible for truthful evidence. Fabricated receipts, false delivery claims, fraudulent chargebacks or attempts to manipulate provider/payment state can lead to restriction, review or escalation.

• Provider onboarding and transaction monitoring can trigger additional KYC/KYB, sanctions, source-of-funds or enhanced-due-diligence requests.
• VSL can restrict, pause or decline a payment/payout capability where ownership is unclear, provider validation fails, risk is unresolved, the transaction appears prohibited or the requested use violates VSL policy.
• Merchants remain responsible for the legality, description, fulfilment and tax/customs treatment of what they sell. Buyers remain responsible for lawful payment instruments, truthful claims and legitimate use of purchased goods/services.
• VSL preserves records and escalates activity to the applicable provider, legal/compliance function or competent authority where legally required or necessary to protect the platform and its users.
• VSL does not publish private screening, internal risk scoring or sensitive investigation material in a seller's public Commerce Passport or marketplace profile.