PayConexDecryptxShieldConexTECS Platform
API Reference
Request SandboxContact Us

NodeJS Use Case for Recurring Payments

Description

In this practical sample app, we demonstrate the user experience and the flexibility that ISVs have at their disposal when integrating with PayConex™ Gateway services, both on the client side and server side.

Let's say we want to build a simple subscription service that charges a customer monthly for the app's services, such as a video streaming service or a web gaming platform.

In the PCI-compliant environment of the Checkout Component and our API, this can be accomplished with simple logic based on Storing a Card on File and Customer- and Merchant-Initiated Transactions. This is illustrated in the following diagram.

Sample App Workflow

PayConex™ NodeJS Sample App for Recurring Payments

PayConex™ NodeJS Sample App for Recurring Payments

  1. Bearer Token Request: The merchant website requests a bearerToken from the back-end controller, which integrates with the PayConex™ V4 API iframe configuration and instance creation. The back end returns the bearerToken to load the Checkout Component. Here, we use a pre-created iframe configuration and overwrite it based on the customer's needs via instance creation. For more, see Overwriting Configuration.
  2. Checkout Component Workflow: The customer completes the form with the PayConex™ token returned for a store transaction and prepared for vaulting based on the prior agreement for recurring payments with the merchant. That is when the savePaymentOption is checked to true by the customer or it is required for the customer to proceed. This workflow is illustrated here: Checkout Component Workflow.
  3. Token and Transaction Processing: The token is sent to the back-end control, where a store transaction request is made via the PayConex™ V4 API. This retrieves the idempotent ShieldConex® tokens, the Bluefin ID, and the vaulted reissuing token. That workflow is covered here: ShieldConex® Card Not Present Transaction Flow.
  4. Token and Subscription Storage: These tokenized/encrypted elements can be safely stored in the database. The subscription type (weekly, monthly, yearly) selected by the user is also included to be stored in the database in the same request.
  5. Recurring Payments: Based on the type of subscription and recurring service, the back end triggers recurring payments using the PayConex™ recurring token that is stored in the database. Specifically, these can be scheduled subsequent MITs.
  6. Subscription Management: The PayConex™ token is stored in the database so that users can cancel their subscription via a UI form. When a cancellation request is made, the back end uses this token to query the database and remove the subscription entry.

📘

Note

This feature can be set via the PayConex v3.8 API SLAPI or from the PayConex™ Portal via UI tools -> RECURRING BILLING.

If a merchant is a large independent software vendor, they may opt to use their own recurring service or solution as Bluefin vaults and supplies the reissuing token in the response of a CIT.

This sample showcases the seamless integration and secure handling of customer data, ensuring a smooth subscription experience for both customers and merchants.

📘

Source Code

The source code can be found at our Github Repository.

For expanding on this sample application, also consider the following: