Skip to main content
Gr4vy provides native mobile SDKs to help you build a high-performance checkout experience tailored specifically for iOS and Android. While Gr4vy offers a web-based “Hosted” Embed experience, these native SDKs allow you to build card forms directly into your app, giving you full control over the user interface, theme, and the overall customer journey. Native Swift and Native Kotlin SDKs provide:
  • 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.
  1. Vaulting: Your app captures the card data and uses the native SDK to securely vault it into a Checkout Session.
  2. 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.
  3. 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. Each repository contains a Sample App that demonstrates how to implement a native card form and handle the 3DS authentication flow.

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.