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: You build the card form from native components in 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.

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.
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

The native SDKs don’t include card entry UI. Your app collects the card number and security code in its own fields and passes them to the SDK, which sends them to Gr4vy. Because your app handles cardholder data, it’s in scope for the Payment Card Industry Data Security Standard (PCI DSS).
  • SAQ D: Neither Self-Assessment Questionnaire (SAQ) A nor SAQ A-EP covers a native app that handles the card number, so you typically validate with SAQ D. SAQ D covers every PCI DSS requirement that applies to your environment, including secure software development and penetration testing.
  • Keeping card data out of your app: If you want to reduce your scope, use the Embed SDKs instead. Gr4vy renders the card form, so your app never handles the card number.
Your acquirer decides how you validate compliance. Depending on your transaction volume, you might need an annual assessment by a Qualified Security Assessor (QSA), regardless of which integration you choose. The integration changes how much of your app and build pipeline that assessment covers.

​
Merchant responsibilities

Your app handles cardholder data, so you are responsible for protecting it on the device and in your build and release pipeline. You must:
  • Pass card data to the SDK as soon as the buyer enters it. Never log, cache, or store the card number or security code on the device.
  • Never transmit, process, or store raw card data on your own servers. Only send it to Gr4vy through the SDK.
  • Complete your annual PCI DSS validation, either SAQ D or an assessment by a QSA, and the Attestation of Compliance (AoC) that goes with it.