Skip to main content
The Cashfree Custom Card Component lets you embed a secure, SDK-managed card input field directly into your iOS application UI. Because the CFCardComponent captures and processes the card number entirely within the SDK, your application never receives the raw card number. This makes the integration suitable for non-PCI merchants, that is, merchants who are not certified to store, process, or transmit raw cardholder data, and who rely on the SDK to handle card data securely on their behalf. The component formats the card number into groups of four digits (up to 16 digits), detects the card network in real time and displays its icon, and runs a Luhn check on every keystroke. After the customer enters 8 digits, the component looks up the card BIN (Bank Identification Number) and TDR (Transaction Discount Rate) automatically. Your application receives only metadata through CFCardListener: the digit count, the Luhn result, BIN information, and TDR information.
This page covers the custom card component integration only. For the standard iOS payment gateway integration, see iOS Integration.
If you are PCI-DSS certified and have access to the raw card number, call .setCardNumber() on CFCard.CFCardBuilder() directly instead of using CFCardComponent. That path follows the standard card payment flow.

Prerequisites

Complete the following tasks before you start the integration: The integration consists of three steps:

Step 1

Create an order

Step 2

Open the payment page

Step 3

Confirm the payment

Step 1: Create an order Server-side

Create an order from your backend server before you process any payment.
This API requires your secret key. Create orders through your server only. Do not call this API directly from your mobile application.
API request for creating an order
Here’s a sample request for creating an order using your desired backend language. Cashfree offers backend SDKs to simplify the integration process.
After successfully creating an order, you will receive a unique order_id and payment_session_id that you need for subsequent steps. You can view the complete API request and response for /orders in the Create Order API.

Step 2: Open the payment page Client-side

After you create the order, set up the card component and open the payment page so the customer can provide their card details.

1. Set up the SDK

The Cashfree iOS SDK is available via CocoaPods. The custom card component requires SDK version 2.2.6 or above and iOS 13.0 or higher. Add the following to your Podfile:
Run pod install to install the dependency, then import the SDK modules in the file where you build the checkout:

2. Complete the payment

To complete the payment, follow these steps:
  1. Add the CFCardComponent to your view.
  2. Create a CFSession object.
  3. Initialise the card component after the session is ready.
  4. Conform to CFCardListener to receive card metadata.
  5. Set up the payment callback.
  6. Build the payment object and initiate the payment.

Add the card component to your view

CFCardComponent is a UIView that you can add in Interface Builder or programmatically. In Interface Builder, set the custom class of a UIView to CFCardComponent (module: CashfreePGCoreSDK) and connect it as an outlet:
To add the component programmatically, create it with a frame and add it to your view hierarchy:
Apply standard UIView styling as needed:
The component manages only the card number field. Collect the cardholder name, expiry month (MM format, for example 12), expiry year (YY format, for example 29 for 2029), and CVV in separate input fields in your checkout UI.

Create a session

The CFSession object holds the session context for the payment. It accepts the payment_session_id and order_id obtained from Step 1, and the Cashfree environment (.SANDBOX or .PRODUCTION). The CFSession.CFSessionBuilder() supports the following methods: The following example shows how to create the session object:

Initialise the card component

Call initializeCardComponent only after you have a valid CFSession. The component uses the session to authenticate the BIN and TDR lookup requests. The initializeCardComponent method accepts the following parameters: The following example initialises the component with a custom font and text colour:

Set up the CFCardListener callback

Conform your view controller to CFCardListener and implement cardMetaData(card_listener_response:). The SDK calls this method each time the card number in CFCardComponent changes.
If cardMetaData updates your UI, such as enabling the pay button, wrap those updates in DispatchQueue.main.async.
The following example enables the pay button only when the card number passes the Luhn check:
The callback delivers a CFCardListenerResponse with the following top-level fields: The meta_data dictionary contains the following keys: The card_bin_info dictionary returned by the BIN lookup contains the following fields:
card_bin_info and tdr_info are only present after the customer has entered at least 8 digits. If the customer deletes digits and the count falls below 8, the SDK clears both keys. If the BIN or TDR lookup fails, the matching key stays nil, while card entry and the Luhn check continue to work. Always check that these keys exist in meta_data before you access them.
When the customer enters the 8th digit, the SDK calls the Cashfree BIN and TDR APIs and includes their results in the same cardMetaData callback. No additional setup is required. The lookups authenticate with the payment_session_id of the session that you passed at initialisation. The component auto-detects the following card networks and displays the corresponding icon: Visa, Mastercard, American Express (Amex), RuPay, Diners Club, Discover, and JCB. The following example illustrates how the meta_data dictionary evolves as the customer enters their card number. The tdr_info contents are omitted.

Set up the payment callback

The SDK exposes the CFResponseDelegate protocol to receive callbacks when the payment flow ends. This protocol consists of two methods:
Register the callback on CFPaymentGatewayService before you call doPayment. Call paymentService.setCallback(self) in your view controller before you initiate payment.
The following example shows how to implement the callback:
Backend verification is mandatory. The SDK signals only that the payment UI flow ended, not that the payment succeeded. Always check the order status from your backend before you show a success message.

Build the payment object and initiate payment

When the customer fills in their card details and taps the pay button, build the CFCard and CFCardPayment objects and call doPayment() on CFPaymentGatewayService.
You must call .setCardComponent(cfCardComponent) on the CFCard builder. Because the SDK manages the card number internally via CFCardComponent, your application does not have access to the raw card number. .setCardComponent() and .setCardNumber() are mutually exclusive. Never call both. The misspelt .setCardComponet() method is deprecated, so use .setCardComponent() instead.
The CFCard.CFCardBuilder() supports the following methods: The CFCardPayment.CFCardPaymentBuilder() supports the following methods: The following example builds the payment object and initiates payment:
There is no public API to read the card number out of CFCardComponent. The SDK uses it securely when you call doPayment.

Sample code

The following example shows a complete custom card component payment flow, including session creation, card component initialisation, metadata handling, and payment initiation.

Sample GitHub code

For a working end-to-end implementation, refer to the sample integration on GitHub.

Step 3: Confirm the payment Server-side

After the SDK delivers a callback via verifyPayment, confirm the payment status from your backend before taking any action. The SDK callback signals only that the payment flow has ended. It does not guarantee a successful payment. To verify an order you can call our /pg/orders endpoint from your backend. You can also use our SDK to achieve the same.
Always verify the order status from your backend before you deliver goods or services to the customer. You can use the Get Order API for this. An order is successful when the order_status is PAID.

Error codes

If a required field or object is missing when you initiate payment, the SDK returns an error through the catch block or the onError callback. CashfreeError is an enum that inherits from the Foundation Error class.
The SDK validation errors are grouped by category as follows:

Session errors

Card errors

Other options

The following optional configurations let you customise the payment screen behaviour. Apply them to the CFCardPayment object before you call doPayment().
To show the authentication web view in full screen, call setFullScreen(true) on the payment object:
To show or hide the cancel button on the authentication screen, call setCancelButtonVisibility on the payment object:
To apply a custom theme to the SDK screens, pass a CFTheme object to setTheme on the payment object: