Security model
The merchant server remains authoritative for product availability, pricing, tax, delivery, discounts, checkout, payments and orders. The client does not accept query parameters or payment-SDK completion as proof of payment.
Verify first
HTTPS discovery, stable store identity and same-origin API links are validated before saved secrets load.
One store, one namespace
Accounts, carts, orders, favorites, markets and push registrations do not cross store boundaries.
Server truth
Idempotency and authoritative state reconciliation protect checkout and order transitions.
Client controls
- Bearer and signed order credentials are stored in iOS Keychain.
- Insecure HTTP, embedded URL credentials, query strings, fragments, cookies, redirects and cross-origin discovery links are rejected for store onboarding.
- Payment methods are unavailable unless the server reports them ready.
- Store switching stops the old environment before another store’s namespace loads.
- Optional analytics fail closed and remain off until explicit consent and server acknowledgement.
- No full card number is stored by Mercato.
Report a vulnerability
Use GitHub’s private vulnerability reporting feature when it is available for the affected repository. If no private channel is shown, open a minimal public issue requesting a private contact without including exploit details, credentials, personal data or active-store secrets.
Mercato security page ↗ iOS security page ↗
Safe testing
Test only systems and data you own or have explicit authorization to assess. Do not access customer data, execute real charges, send transactional messages, purchase shipping labels, degrade service or use production webhooks. The embedded demo and deterministic adapters are intended for safe validation.
Security is shared
Merchant deployment, ProcessWire access control, server updates, TLS, payment credentials, webhook verification, backup protection, retention and incident response remain merchant operational responsibilities.