Security Model

AccruPay is designed so that raw card data never passes through your servers. This is not just a recommendation — it is enforced by the architecture.

Card data flow

When a customer submits a payment form, the React SDK sends card fields directly to the payment provider over TLS. Your backend receives only the result of that operation, never the card numbers themselves.

Browser (React SDK)
  │
  │  card number, expiry, CVC — over TLS
  ▼
Payment Provider
  │
  │  authorization result
  ▼
AccruPay API ──► Your backend (verify)

Your server is involved at two points — starting the session and verifying the result — but it is never in the card data path.

What this means for PCI compliance

Because card data bypasses your infrastructure entirely, you may qualify for SAQ A (or its equivalent), the lightest PCI DSS self-assessment questionnaire. Consult your QSA to confirm scope for your specific setup.

The two-credential model

AccruPay uses two credentials with different trust levels:

Credential	Header / Field	Where it runs	What it can do
apiSecret	accrupay-api-secret	Your backend only	Start sessions, verify results, charge stored cards, access transaction data
merchantPublicId	React SDK prop	Browser	Render card fields, query status of sessions you created

These credentials serve different purposes and must be kept in their respective environments.

Trust boundaries

Operation	Credential	Runs in
Start payment session	apiSecret	Your backend
Render card fields	merchantPublicId	Browser
Submit card data	Provider SDK — no AccruPay credential	Browser → Provider
Verify payment result	apiSecret	Your backend

API secret exposure

danger

If your apiSecret is compromised, an attacker can:

• Start payment sessions on your behalf
• Verify and retrieve transaction data for all transactions
• Charge stored payment methods against your customers
• Access all merchant configuration, including connected provider accounts

Treat apiSecret with the same care as a private key. Never commit it, log it, or send it to the browser.

What merchantPublicId exposes

merchantPublicId is safe to ship in frontend code. An attacker who obtains it:

Can:

• Query the status of payment sessions that you created (session IDs are required — they cannot be enumerated)

Cannot:

• Create or modify transactions
• Access your transaction list or customer data
• Charge stored cards
• Access stored payment methods

Security checklist

• Store apiSecret in an environment variable, never in source code
• Never send apiSecret in a response to the browser
• Start sessions and verify results only from your backend
• Use merchantPublicId in the React SDK — never apiSecret
• Rotate apiSecret immediately if you suspect exposure