- Direct Embedding: Native card forms are embedded directly into your app’s view hierarchy. There is no need to open a web view to capture payment details.
- Total UI Control: You have full control over the look and feel, ensuring the checkout process is indistinguishable from the rest of your app.
- Native 3DS Support: Authentication happens within a native interface. This avoids clunky browser redirects and provides a much smoother flow for the customer.
- Performance: Native components offer better responsiveness and smoother animations compared to web-based alternatives.
Native 3DS workflow
To provide a seamless experience, these SDKs support performing 3DS authentication before a transaction is created.- Vaulting: Your app captures the card data and uses the native SDK to securely vault it into a Checkout Session.
- Authentication: The SDK initiates the 3DS challenge directly in the client. The user completes the challenge (for example, via a fingerprint or a one-time password) within the app.
- Completion: Once the 3DS flow is finished, the Checkout Session is updated with the authentication data. This session can then be used by your backend to process the transaction.
SDK repositories
You can find the SDKs and implementation examples in the GitHub repositories.Swift SDK
Native Swift SDK for building custom payment experiences on iOS devices.
Kotlin SDK
Native Kotlin SDK for building custom payment experiences on Android devices.
Self-certification and scope
Following the logic established by the PCI Security Standards Council (PCI SSC) and adopted by major providers, using a native mobile SDK for card entry typically qualifies you for a significantly reduced compliance scope.- SAQ A Eligibility: When you use the official SDKs to send data directly to Gr4vy, you generally qualify for the simplest form of PCI validation: Self-Assessment Questionnaire A (SAQ A).
- Comparison to Web: In a web environment, total control of the payment page usually requires SAQ A-EP (which has ~191 questions). On mobile, because the app is a “consumer-facing” device and the SDK handles the secure transmission, the PCI requirements are more flexible, allowing you to use the much shorter SAQ A (only ~22 questions).
Merchant responsibilities
While the scope is reduced, you are still responsible for ensuring the overall security of your app. To maintain your SAQ A eligibility, you must:- Avoid Server-Side Handling: Never transmit, process, or store raw cardholder data (PAN, CVV) on your own servers.
- Use Official SDKs: Rely on the Gr4vy Swift and Kotlin SDKs to handle the tokenization and 3DS flows.
- Annual Attestation: Complete an annual Self-Assessment Questionnaire (SAQ A) and Attestation of Compliance (AoC) to declare that you are following these secure practices.