Build a credit card payments extension with a checkout UI extension

Checkout UI extensions enable Partners to define additional fields required for processing credit cards with a payments extension. Partners can then collect all essential information upfront, such as an installments payment plan, directly on the checkout page before a payment is initiated. This improvement simplifies the checkout process and offers a smoother buyer experience.

Anchor to What you'll learnWhat you'll learn

In this tutorial, you'll learn how to do the following tasks:

• Create a checkout UI extension
• Create a credit card payments extension with extensibility
• Explore the payment, refund, void, reject and capture session flows, and how to implement them yourself

Anchor to RequirementsRequirements

• Install Shopify CLI
• Create a Shopify Partner account and apply to become a payments partner
• Create a development store
• Create an encryption certificate

Anchor to Step 1: Scaffold an appStep 1: Scaffold an app

To build an extensible credit card payments extension, you will need to create a new credit card app or use an existing credit card app with extensibility features turned on by Shopify.

If you opt to create a new app, begin by using the Shopify CLI to set up your app. As a first step, we recommend deploying a skeleton app to establish a base for customization.

Anchor to Step 2: Create a checkout UI extensionStep 2: Create a checkout UI extension

After creating your app, generate a checkout UI extension and deploy your app to Shopify. This extension will be used to collect additional information that's required to process a payment.

1. Use the Shopify CLI to scaffold a checkout UI extension for your app.

2. Name your extension and choose to work in TypeScript React.

   Note

   A sample extension, written in Typescript React, is shown below in the Sample Checkout UI Extension section. Please make sure to use the extension target and APIs as shown in the example.

3. After you generate the extension, deploy your app to Shopify Partners. This will allow you to link the checkout UI extension with your payments app extension in the next section.

4. Navigate to your app in Shopify Partners (Apps > Your App).

Anchor to Step 3: Create a payments extensionStep 3: Create a payments extension

Your Shopify app becomes a payments app after you've created and configured your payments extension.

1. Run the following command to start generating your payments extension:

   Terminal

   npmyarnpnpm

   Copy

   $

   $

   npm shopify app generate extension

   $

   $

   yarn shopify app generate extension

   $

   $

   pnpm shopify app generate extension

   npm shopify app generate extensionyarn shopify app generate extensionpnpm shopify app generate extension

2. When prompted, choose your organization and create a new app.

3. When prompted for Type of extension, select Payments App Extension > Credit Card and name your extension.

Anchor to Step 4: Configure your payments app extensionStep 4: Configure your payments app extension

Configuration of an extensible credit card payments app extension is similar to a Credit Card payments app extension.

Your payments app extension configures the following fields:

The UI extension generated in Create a checkout UI extension will determine what fields, validation, and form submission behavior is presented to buyers during checkout.

Anchor to UI ExtensionUI Extension

This is where you link the checkout extension you previously built with your new payment app extension to tie them together.

Anchor to UI Extension Field DefinitionsUI Extension Field Definitions

Specify the fields your UI extensions should collect to ensure the payment method validates and receives the correct data from the front end.

Anchor to Step 5: Deploy your extensionStep 5: Deploy your extension

Create and release an app version with the deploy command.

1. Navigate to your app directory.
2. Run the following command:

   Terminal

   Copy

   $

   $

   shopify app deploy

An app version created using Shopify CLI contains the following:

• The app configuration from the local configuration file. If the include_config_on_deploy flag is not set or false, the configuration from the active app version will be used instead.

• The local version of the app's CLI-managed extensions. If you have an extension in your deployed app, but the extension code doesn't exist locally, then the extension isn't included in your app version.

Releasing an app version replaces the current active version that's served to stores with your app installed. It might take several minutes for app users to be upgraded to the new version.

Anchor to Step 6: Preview payment extensions on a development storeStep 6: Preview payment extensions on a development store

Once this version has been released, follow these steps to install your app on your development store:

1. From the app splash page, enter an account name.

2. Select Ready > Unstable and click Submit.

3. In the banner, click Return to Shopify.

4. Enable test mode.

5. Click Activate.

6. You can select Resolve to complete the payment, or Reject to cancel and go back.

Anchor to Explore the payment processing flowsExplore the payment processing flows

The payments app functions similarly to the credit card payment method, allowing you to gather additional information from the buyer at the outset to facilitate payment processing. The primary distinction is that checkout UI extension data is included in the start_payment_session body.

Outlined below is a comprehensive diagram depicting the potential flow for processing an extensible credit card payment. It's important to note that the pending state is optional; you can directly proceed to either resolve or reject the payment if there is no need to place it in a pending state. For further details on processing credit card payments, please refer to this resource.

Once we start the payment session with your payments app, that initiation will also contain the metadata in a shape similar to what was specified within the field definitions. A sample payment session payload of what is to be expected can be seen below.

Anchor to Payment sessionPayment session

Payments with payments apps are processed asynchronously. When the buyer completes their checkout, a request will be sent from Shopify to the Payment session URL defined in Configure your payments app extension, with the checkout and payment details. The Payments app should respond with HTTP 2xx to indicate that the payment session was started, and should begin processing the extensible credit card payment at this point.

The new metadata we are passing through payment session would be contained within the payment_method request parameters under attributes:

Anchor to Payment session with localized fieldsPayment session with localized fields

For certain countries that require additional fields on orders, localized_fields are included in the payload inside the transaction_metadata object. In the case of Brazil, localized_fields contains the CPF value. As a result of this, payment app developers won't need to manually add a CPF field to the payments app.

Anchor to ResolveResolve

After the payments app has responded to the initial start payment session request, it should begin processing the payment. Since this is an asynchronous process, the payments app will be performing the next step independently, through the paymentSessionResolve mutation on the Payments Apps GraphQL API. This mutation will resolve the payment session, indicating that the payment was successful.

After this, the payment will be marked as resolved in Shopify.

Anchor to RejectReject

If a payment was unsuccessful for any reason, then payments app must use the paymentSessionReject mutation.

Anchor to ErrorError

This section describes the reasons you can use to reject a payment session.

Anchor to Refund SessionRefund Session

The refund flow begins with an HTTP POST request sent from Shopify to the payments app's refund session URL. Shopify must receive an HTTP 201 (Created) response for the refund session creation to be successful. For more information about refund sessions and how to reject or resolve refund sessions, refer to Explore refund sessions.

Example request body:

Anchor to ResolveResolve

After the app has successfully processed the refund request, it's resolved by using the refundSessionResolve mutation. The id argument corresponds to the gid of the refund.

Example GraphQL mutation:

After this, the refund will be marked as resolved in Shopify.

Anchor to RejectReject

If the app can't process a refund, then it needs to reject it. You should only reject a refund in the case of final and irrecoverable errors. Otherwise, you can attempt to process the refund again.

The refund is rejected using the refundSessionReject mutation.

As part of the rejection, a reason why the refund was rejected must be included as part of RefundSessionRejectionReasonInput.

Anchor to Capture SessionCapture Session

A capture can only be performed when the payment initiated by Shopify has a kind property with a value of authorization. With an authorization, the app places a hold on funds and then replies to Shopify's capture request.

The capture flow begins with an HTTP POST request sent from Shopify to the payments app's capture session URL. You can read more about capture sessions and how to reject or resolve capture sessions here.

Example request body:

Anchor to ResolveResolve

After the app has successfully processed the capture request from Shopify, it's resolved using the captureSessionResolve mutation on the Payments Apps GraphQL API.

Example GraphQL mutation:

After this, the capture will be marked as resolved in Shopify.

Anchor to RejectReject

If you don't want to process a capture request, then you should reject it. You might want to reject a capture if authorization has expired or if you suspect that the request is fraudulent or high risk. You should only reject a capture in the case of final and irrecoverable errors. Otherwise, you should re-attempt to resolve the capture.

The app rejects a capture using the captureSessionReject mutation.

As part of the rejection, you need to include a reason why the capture was rejected as part of CaptureSessionRejectionReasonInput.

Example GraphQL mutation:

Anchor to Void SessionVoid Session

A void can only be performed when the payment initiated by Shopify has a kind property with a value of authorization.

The void flow begins with an HTTP POST request sent from Shopify to the payments app's void session URL. You can read more about void sessions and how to reject or resolve void sessions here.

Example request body:

Anchor to ResolveResolve

After the app has successfully processed the void request, it is resolved using the voidSessionResolve mutation on the Payments Apps GraphQL API.

Example GraphQL mutation:

After this, the void will be marked as resolved in Shopify.

Anchor to RejectReject

If your app can't process a void request, then you should reject it. You should only reject a void in the case of final and irrecoverable errors. Otherwise, you can attempt to resolve the void again.

You can reject a void using the voidSessionReject mutation. As part of the rejection, you need to include a reason why the void was rejected as part of VoidSessionRejectionReasonInput.

Example GraphQL mutation:

Anchor to Sample Checkout UI ExtensionSample Checkout UI Extension

This sample code shows what checkout UI extension could look like for a credit card payments app. This code would go in the Checkout.tsx file of your checkout UI extension:

Anchor to BIN Range ConfigurationBIN Range Configuration

This example exposes the BIN number entered by buyers to the checkout UI extension so the extension can make decisions about what to display. To get the BIN number entered for the credit card on checkout, the following code can be used:

Anchor to Known limitationsKnown limitations

• App deployments from the Partner Dashboard only pickup checkout UI extensions if they have previously been deployed and released. If you want to use the Partner Dashboard UI to deploy new versions of your app, make sure you've previously deployed and released the corresponding checkout UI extension from the CLI first.

Anchor to RestrictionsRestrictions

• Payments extensions using checkout UI extensions should not request scopes enabling network access. This will result in the extension being rejected during review. Instead of fetching data using an external network call, consider storing the data using Metafields for your app & accessing the same later.

• Companion app:

  • If access to order data is needed for any reason, a companion app may be used to request and gain access to the data from the merchant by requesting read_all_orders scope for that app. The only scopes that payments app extension should not request for are write_checkout_extension_payments and write_payment_sessions.
  • If the companion app is using web pixels, you will need to request access to the consent feature to ensure that the pixel fires consistently. Please ask partner manager to get you the access.

Anchor to Tutorial Complete!Tutorial Complete!

Congratulations! You set up a credit card payments extension with UI extensibility.