EdfaPay Logo

Security & Compliance

How the SDK keeps your app out of PCI scope with the bundled UI, enforces transport security, avoids on-device storage of card data, and handles Strong Customer Authentication. Includes the responsible-disclosure channel.

PCI DSS Scope

With the bundled CardPay UI, card data is captured inside the SDK's Compose surface, sent via TLS direct to EdfaPay, and never persisted in your process — on Flutter it never crosses the Flutter ↔ native bridge or your Dart code. 3-D Secure 2 challenges render in an in-SDK WebView targeting only the issuer's domain, and logs redact the API key, PAN (last 4 preserved), CVV, and recurring tokens.

Headless makes you PCI-relevant

If you go headless (sale(...) with your own card capture), you become PCI-relevant — scope to SAQ-A-EP and never log raw PANs.

Transport Security

The SDK enforces modern transport security and signs every payment-affecting call for you.

TLS 1.2+

Enforced by the underlying platform HTTP engines (OkHttp on Android, Darwin on iOS).

X-API-KEY header

Attached to every request automatically — never put it in URLs, query strings, or logs.

Operation hash

Every payment-affecting call is signed with a hash derived from your API key plus payload-identifying fields. The SDK handles this.

Storage on Device

The SDK does not write card numbers, CVVs, or tokens to disk. Your app is responsible for any persistence of transactionId / recurringToken — treat them as sensitive customer data.

Where to store tokens

Use Keystore on Android, Keychain on iOS, or flutter_secure_storage on Flutter for any transactionId / recurringToken you keep.

Strong Customer Authentication

3-D Secure 2 is automatic when the issuer requires it. The WebView is presented full-screen by the SDK; the final result returns through onTransactionSuccess / onTransactionFailure.

Responsible Disclosure

Found a security issue? Email security@edfapay.com — please do not file a public issue.

Next Step

Error Handling