Security & PCI Scope

What Migo handles

Migo operates as a PCI-DSS Level 1 service provider. Inside our perimeter we handle:

• Primary Account Numbers (PANs) — stored tokenized, never echoed.
• Cardholder data vaulting and tokenization.
• 3-D Secure authentication (ACS integration with card networks).
• Encryption at rest and in transit (TLS 1.2+).
• Card-processor integration, including key exchange for raw card-present flows.
• Fraud scoring and suspensions.

What you handle

Your PCI scope depends on how you collect the card.

Flow	Your PCI scope	Notes
Tokenized via Migo Wallet SDK	SAQ-A	Card data never touches your servers. Recommended.
Migo-hosted redirect / iframe	SAQ-A	Card fields in an iframe owned by Migo.
Your UI, tokenization client-side	SAQ-A-EP	JS SDK posts directly to Migo; you never see the PAN.
Your servers collect full PAN	SAQ-D	Full PCI-DSS scope. Migo discourages this path.
Card-present (POS)	SAQ-P2PE	The hardware terminal encrypts card data; Migo decrypts it inside its PCI-scoped environment.

What you must never do

• Never log the PAN, CVV, track data, or PIN — not even once, not even in development.
• Never store CVV or PIN. Migo does not either.
• Never email full PANs.
• Never put tokens (cardId) in URLs logged to third-party analytics. They are not sensitive like a PAN but they identify a real card.

Network controls

• TLS 1.2+ required on all API traffic. TLS 1.0 and 1.1 rejected.
• HSTS with includeSubDomains; preload.
• IP allowlisting available for server-to-server traffic (request from your Migo contact).
• Webhook signatures — Ed25519 webhook signing is the target standard but is not yet enforced end-to-end across the platform. Inbound processor hooks currently use processor-specific HMAC / signature schemes. Confirm the active scheme and public key with Migo before relying on signature verification.

Key management

• Migo signs JWTs with Ed25519. The public key is shared with you — validate every JWT signature before trusting the claims.
• If you enable request signing, you generate an Ed25519 key pair and share the public key with Migo. Keep the private key in your secret manager (AWS KMS, Vault, etc.) — never in code.
• Rotate keys at least annually. Migo will coordinate a zero-downtime rotation.

Device integrity (mobile app attestation)

Mobile clients can attest the integrity of the device and app before performing sensitive operations. The flow is exposed on the Wallet Gateway under /integrity/app and requires a valid JWT (Bearer auth):

1. GET /integrity/app — returns a validation hash for the calling application. The application is identified by the applicationid HTTP header (e.g. com.migo.ali).
2. The client generates an integrity token on-device using the Google Play Integrity API.
3. POST /integrity/app — submit the attestation result with { hash, applicationId, token }. Migo validates the hash, application ID, and integrity token.

Failed checks surface as integrity errors (e.g. unrecognized app version, device integrity, or licensing status; expired/invalid integrity token; invalid hash or application ID).

Monitoring & audit

• Every authenticated request is correlated to an internal trace. Provide the request timestamp and details when opening a support ticket so Migo can correlate it.
• An audit.* event catalog (e.g. permission grants/revocations, CMS user login) is documented as a target contract but not yet emitted by the platform. Do not depend on audit webhooks until Migo confirms emission.
• Unusual patterns (velocity, BIN mismatch, country mismatch) can trigger automatic suspensions — see Middleware Suspensions.

Incident response

If you suspect a key, secret, or token has leaked:

1. Contact soporte@migopayments.com immediately.
2. Rotate the affected credential on your side.
3. Migo will revoke the compromised key and issue a new one.

Compliance certifications

• PCI-DSS Level 1 Service Provider
• SOC 2 report available under NDA — contact your Migo account manager

For data-residency, GDPR, and regional-compliance specifics, contact Migo legal.