WordPress.com Store’s Billing API enables vendors to sell subscriptions for their SaaS products on WordPress.com Store, via our in-house billing and subscription system. WordPress.com Store’s Billing API supports recurring payments.
The purchase flow
The customer must go through the vendor application to select a specific plan. The following is the SaaS product subscription creation event life cycle:
1. The customer follows a link from a WordPress.com Store plugin page and lands on the vendor application
The flow starts when a customer visits the WordPress.com Store plugin page. At this stage, customers are already authenticated in WordPress.com. The customer is redirected to the Vendor Application by clicking on the buy now button on the listing page. The Vendor Application landing page will receive additional GET parameters to facilitate the purchase flow like customer and site identifiers.
The GET parameter is called
uuid. It comprises two sections: the user id and blog id, separated by a + symbol. The user id is always the first part, and the site id is the second part.
If there are several plans available in the vendor application, the vendor can have the customers choose one before initiating the purchase. The vendor application may also decide to not show the customer anything and initiate the purchase immediately, as described in the next step.
2. Create billing intent
The vendor application needs to make an API call to WordPress.com’s API with the subscription plan information. It will receive a checkout URL in the response. Please review the API documentation for more details.
The subscription plan information includes the plan name, price, billing period, billing interval, and a return URL. The return URL is a URL in the vendor application where WordPress.com will redirect the customer after they complete the purchase on WordPress.com.
The vendor application needs to redirect customers to the checkout URL for them to confirm and pay for the subscription. The checkout URL is the shopping cart page on WordPress.com and it will have the subscription plan pre-filled when a customer visits it.
The response of the billing intent from WordPress.com API contains a unique billing intent id, which the vendor can use to associate the subscription with the vendor application’s internal customer ID. Please review the API documentation for more details.
If the vendor initiates the purchase immediately when the customer lands on the application and then redirects to WordPress.com checkout URL during the same request, the operation will take less than a few seconds to complete. The experience for the customer is seamless as if they never left WordPress.com.
3. Customer confirms the purchase
After the vendor application redirects the customer to the checkout URL on WordPress.com, the customer will have to confirm and pay for the subscription. The customer goes through a familiar checkout experience, with all the necessary payment information pre-filled if they’ve purchased from WordPress.com before.
4. Customer is redirected to the vendor application
After the customer completes the purchase, they are redirected to the return URL provided by the vendor while creating the billing intent in the previous steps. If the vendor application hasn’t already signed up the customer, it can do it in this phase. The return URL passes the billing intent id in a GET parameter, so the vendor application can associate it with the internal customer ID.
At this point, WordPress.com also makes a webhook call to the webhook URL provided by the vendor. Please review the API documentation for more details.
Note: In most cases, the webhook will be sent before the customer is redirected to the vendor application. But in some cases, the customers will be redirected to the page before the webhook event is received by the vendor application due to the asynchronous operations.