Cloudflare provides platform capabilities such as DDoS mitigation, Web Application Firewall controls, managed security rules and rate-limiting controls. VSL's public compliance page does not claim a particular Cloudflare plan, every optional product, or that every possible rule is enabled. The relevant statement is that Cloudflare forms part of VSL's edge/security architecture and can be configured to reduce malicious or abusive traffic before it reaches the application.

Cloudflare's own documentation describes autonomous DDoS protection, managed WAF rules and rate limiting for abuse such as brute-force attacks, credential stuffing, scraping or resource exhaustion. VSL combines edge controls with application-level authentication and validation rather than treating CDN/WAF protection as a replacement for secure code.

• Authenticated areas use the VSL account/session boundary before private user data or actions are exposed.
• VSL applies ownership checks before seller-scoped payment, social, delivery, AI or Commerce Passport records are acted on.
• State-changing web forms/endpoints use request-integrity controls such as CSRF tokens where applicable.
• Input is validated server-side; browser state, query parameters or JavaScript UI alone are not trusted as authority for payment or ownership.
• High-impact AI actions add a second permission layer through OAuth scopes/capabilities, prepared actions and confirmation/delegation controls.

Fincra, NOWPayments and Busha have different API/webhook contracts. VSL verifies authenticity/integrity using the provider's supported mechanism, matches the event to the expected VSL/provider reference, rejects malformed or unrelated events, and applies idempotent transitions so a provider retry cannot duplicate the commercial effect.

VSL's financial state is therefore not driven by a customer-controlled redirect, a chat message or a visual success screen. Server-side provider evidence and VSL's own canonical record remain authoritative.

• Provider API keys, webhook secrets, OAuth client secrets, database credentials and encryption keys are server-side configuration and are not public Commerce Passport data.
• VSL logs redact or mask sensitive identity/payment values and are not used as a convenience copy of raw KYC documents or provider credentials.
• Where VSL stores sensitive integration tokens/credentials, the application design uses protected server-side storage and avoids exposing them to the browser.
• Security-sensitive evidence shared with vendors or enterprise reviewers can be restricted to an NDA/controlled review rather than posted publicly.

VSL delivery workflows can use a textual delivery address, stored destination latitude/longitude and live courier coordinates when the courier/actor provides them. Google Maps is used in parts of the delivery experience to geocode or display destinations/routes; VSL also contains Mapbox support in its route implementation.

Google documents that Maps Platform requests can log an account/project identifier, IP address, request URL/parameters, request date/time and request headers. Geocoding can return a place ID, latitude/longitude, Plus Code and expanded address details. VSL limits map queries to the personal detail required by the location workflow and follows the Maps Platform's data-use, caching, attribution and key-security rules.

VSL restricts Google Maps API keys to the applications/APIs that need them, following Google's published security guidance. Client-visible keys are not treated as unrestricted secrets: application/API restrictions and server-side controls are part of the defence.

• VSL limits production access to authorised administrators and service accounts with the minimum permissions needed.
• VSL keeps production configuration and credentials outside user-accessible code and does not copy them into public repositories or support messages.
• VSL tests backup and recovery procedures in proportion to business criticality and protects sensitive backups with access controls comparable to the live data.
• VSL treats software/dependency updates and vulnerability remediation as ongoing operations, not a one-time launch task.
• VSL logs security events, provider failures and material application errors with enough detail to investigate incidents without unnecessarily duplicating sensitive data.

1. Contain the affected account, endpoint, credential, integration or provider path.
2. Preserve relevant technical/payment evidence and establish the affected users/transactions/data.
3. Revoke or rotate compromised credentials and close the exploited condition.
4. Assess legal/provider notification requirements, including privacy-breach thresholds and payment-provider obligations.
5. Notify affected users or authorities where required, using verified facts rather than speculation.
6. Remediate, monitor for recurrence and document lessons/actions.