Minimal metadata, clear boundaries, Stripe-hosted payment collection.
VeilPay is a payment forwarding layer, not a card-data processor and not an order database. The security posture stays simple because the system deliberately handles less.
Requests are validated with shared secrets and timestamp checks.
PAN, CVC, and 3DS challenges never touch VeilPay.
Customer data, line items, and fulfillment live in WooCommerce.
HMAC-signed requests
Woo to VeilPay and VeilPay to Woo requests use signatures and timestamp validation so replay and tampering attempts can be rejected quickly.
Test and live separation
Credentials, webhook secrets, and operational environments remain isolated. Sandbox verification happens before live traffic touches production keys.
Minimal Stripe metadata
Stripe gets a generic description, total amount, currency, and reference. That smaller surface is easier to audit and easier to reason about.
Hosted payment collection
Card entry stays on Stripe-hosted pages, which keeps PCI-sensitive collection outside WooCommerce and outside VeilPay.
Order truth stays in Woo
VeilPay does not need to mirror catalog data or customer order detail to reconcile payment outcomes back to WooCommerce.
Compliance-neutral positioning
VeilPay is a minimization tool, not a bypass. Merchants still have to comply with Stripe policies, KYC rules, and card network requirements.
| Security topic | VeilPay position |
|---|---|
| Card data handling | Never collected or stored by VeilPay. |
| Order persistence | Full order remains in WooCommerce. |
| Outbound Stripe payload | Reduced to generic payment context. |
| Inbound webhook mapping | Opaque reference maps payment outcome to Woo order. |
| Disclosure channel | Security reports route through the disclosure page and direct contact. |
Need a security walkthrough?
We can walk through what data crosses boundaries, what stays in WooCommerce, and how to stage sandbox validation before launch.