Use the Recharge API to build a custom customer portal

Allow customers to manage their subscriptions, update billing information, and see their purchase history with a custom-built portal.

Leverage the Recharge API and build a custom customer portal that provides customers complete control over their subscriptions.

📘

Platform

  • Custom

Overview

Utilize the Recharge API to build a custom customer portal for more flexibility, or to integrate subscription actions into your platform's existing customer portal. With these options, you can pull in all subscription data and perform actions allowing customers to manage their subscriptions.


Custom customer portal architecture

A custom customer portal uses both backend architecture and frontend architecture.

  • The backend architecture is responsible for sending API calls and receiving responses
  • The frontend architecture is the user interface that the customer interacts with

Backend architecture

The backend architecture of a custom customer portal is compromised of the following:

  • Customer Portal Application
  • Middleware
  • The Recharge API

In this example, the Customer Portal Application reaches out to middleware hosted on a merchant's domain. The middleware handles the API calls to the Recharge API and passes along the appropriate API responses to the domain's frontend.

Middleware is necessary for creating a custom customer portal because the Recharge API does not support CORS, so connecting to the API from another domain is not possible. Middleware also provides secure storage of Recharge API keys on the backend.

This architecture allows a single API call result in multiple responses. For example, when a customer adds a one-time product to a shipment, a single API call can add the one-time product to the customer's subscription while also updating metafields on a customer object to track that customer's order history for a loyalty program.

Frontend architecture

The frontend architecture receives API responses and acts as the user interface that customers use when managing their subscriptions. The general frontend architecture of a custom customer portal is compromised of the following:

  • Customer
  • Subscriptions
  • Delivery Schedule
  • Purchase History
  • Addresses
  • Payment Methods

It is not required to structure a custom customer portal using the same frontend architecture, however, this example provides a general overview of how to configure a custom customer portal.

Decide what actions a customer can perform under each component of the frontend architecture. For example, under the Subscriptions component it's possible to offer the following actions to your customers:

  • Change the charge date
  • Change the frequency
  • Skip order
  • Swap product
  • Cancel subscription
  • Add one-time product

Step 1 - Retrieve the customer hash

The customer_hash is used when a customer accesses their customer portal in a Recharge-hosted customer portal. The customer_hash authenticates the user and maps the user to the correct customer_id. The customer_id is then used to locate the correct customer details.

For custom customer portals, use the customer_hash or customer's email address during login to map the user to the correct customer_id. After retrieving the customer_id build the different features and their corresponding actions for the custom customer portal.

Use the following directions to retrieve a list of customers' customer hashes:

  1. From the merchant portal, click Data and select Exports.
  2. Click Create export.
  3. From the Export type menu, select Customers and add your email address to the export.
  4. Open the Export and view the file.
  5. Retrieve the customer_hash from the hash column.

Step 2 - Create actions in the customer portal

There are several different features of the customer portal that you can build. Each feature has specific corresponding actions a customer can take in the customer portal. In the following tables, each feature and its corresponding action shows the API requests needed to build the customer portal.

🚧

Note:

The following request actions use API version 2021-11.

View Subscriptions

View Subscriptions features typically live under the Subscriptions section of the customer portal. The recommended actions for this feature allow a customer to view their subscriptions and add a subscription directly from the customer portal.

ActionRequestAPI Reference link
View current subscriptions and subscription detailsGET /subscriptions?customer_id=<customer_id>List subscriptions
View single subscription and subscription detailsGET /subscriptions/<subscription_id>Retrieve a subscription
Add a subscriptionPOST /subscriptionsCreate a subscription

Edit Subscriptions

Edit Subscriptions features typically live under the Subscriptions section of the customer portal. The recommended actions for this feature allow a customer to edit and manage their subscriptions, add a one-time item, or cancel their subscription.

ActionRequestAPI Reference Link
Change charge date/next shipment of productPOST /subscriptions/<subscription_id>/set_next_charge_dateChange a subscription charge date
Order now/Process chargePOST /charges/<charge_id>/processProcess a charge
Skip shipment/Skip chargePOST /charges/<charge_id>/skipSkip a charge
Unskip a shipment/Unskip chargePOST /charges/<charge_id>/unskipUnskip a charge
Add discount code to a single chargePOST /charges/<charge_id>/appy_discountApply a discount
Add discount code to an Address ID/Add discount code to all subscriptions under a customer's Address IDPUT /addresses/<address_id>Update an address
Update subscriptionPUT /subscriptions/<subscription_id>Update a subscription
Swap out subscription productPUT /subscriptions/<subscription_id>Update a subscription
Add one-time product to next shipmentPOST /onetimes

Notes:
Use the add_to_next_charge boolean if there is a known queued charge to add to so it ships out with the next subscription shipment.

If there is no queued charge, set the date for the one-time to be processed with next_charge_scheduled_at.
Create a onetime
Change delivery schedulePUT /subscriptions/<subscription_id>

Notes:
This request updates the subscription and changes the order_interval_frequency and order_interval_unit.

The charge_interval_frequency must also be updated to align the new schedule.
Update a subscription
Cancel subscriptionPOST /subscriptions/<subscription_id>/cancelCancel a subscription

Delivery Schedule

Delivery Schedule features typically live under the Subscriptions or Delivery Schedule sections of the customer portal. The recommended actions for this feature allow a customer to see upcoming charges and skip or unskip a shipment.

ActionRequestAPI Reference link
See upcoming shipments/chargesGET /customers/<customer_id>/delivery_scheduleRetrieve a customer delivery schedule
Skip charge/shipmentPOST /charges/<charge_id>/skipSkip a charge
Unskip charge/shipmentPOST /charges/<charge_id>/unskipUnskip a charge

Purchase History

Purchase History features typically live under the Subscriptions or Purchase History sections of the customer portal. The recommended actions for this feature allow a customer to see past charges, charge statuses, and order details.

ActionRequestAPI Reference link
See past chargesGET /charges?customer_id=<customer_id>List charges
Show charge status (error, success, pending, etc.)GET /charges?customer_id=<customer_id>&status=queued, refunded, partially_refunded, success, errorList charges
View order detailsGET /orders/<order_id>Retrieve an order

Shipping Addresses and Payment Methods

Shipping Address and Payment Method features typically live under separate sections of the customer portal, but these features rely on one other to store data. Payment Methods are stored under Shipping Addresses (Address IDs). The recommended actions for these features allow a customer to manage their shipping addresses and payment methods.

ActionRequestAPI Reference link
Shipping AddressesGET /payment_methods?customer_id=<customer_id>

Notes:
Each Address ID for a customer has its own Payment Method and each Payment Method has its own Billing Address.
List payment methods
EmailThe customer object has an email attribute for this data.The customer object
Data for card(s) on fileGET /payment_methods?customer_id=<customer_id>List payment methods
View all addressesGET /addresses?customer_id=<customer_id>List addresses
Update Shipping addressPOST /subscriptions/<subscription_id>/change_address

Notes:
If there are multiple subscriptions that need updated, the request must be made multiple times.
Change a subscription address
Update Billing AddressPUT /payment_methods/<payment_method_id>

Notes:
Each Payment Method has its own Billing Address data that can be updated.
Update a payment method
Add additional addressesPOST /addresses

Notes:
Any additional Addresses need a Payment Method attached to it for charges to process under that Payment Method.
Create an address
Add new payment methodPOST /payment_methods

Notes:
Card data will need to be tokenized separately from Recharge API.

New Payment Method will need to be set to a specific Address ID for charges under that Address to be processed.
Create a payment method

Update an address
Update card for paymentPOST /payment_methods

Notes:
Card data will need to be tokenized separately from Recharge API.

Update Address ID with the ID of the new payment method under payment_method_id on the Address object.
Create a payment method

Update an address

Create a demo customer portal using the Recharge API

Use Postman to create a demo customer portal using a test Recharge Environment and pre-configured test Collections. To create a demo customer portal, use the Custom customer portal tutorials.


Need Help? Contact Us