Purchases
A purchase is the state of what a customer currently should have “access” to. This includes one-time prices, subscriptions or installment plans. A purchase is directly tied 1:1 to a product, price and optionally a variant.Purchase Lifecycle
A purchase has 3 lifecycle events: created, invoked, and revoked. Each event has a corresponding action that can be implemented in your integration.Purchase Created
A purchase is created the first time a customer completes an order, or when a person upgrades or downgrades a subscription. A purchase can also be created when a customer makes a one-time purchase. Typically, this is when an integration provides “access” to something.Purchase Revoked
A purchase can be revoked either manually by the Merchant or automatically. A purchase can be manually revoked if it is a one-time purchase. The merchant will see a “Revoke” button next to the purchase in the Merchant’s admin panel. A purchase can also be automatically revoked. This can happen when a subscription is canceled or expired, but it can also occur when a customer changes their subscription plan, through an upgrade or downgrade, for instance. While a new purchase will be created, the old purchase will be revoked.When a merchant revokes a purchase that is tied to a subscription, the
subscription will be canceled when the purchase is revoked.
Purchase Invoked
A purchase is ‘invoked’ when a purchase has been previously revoked and then un-revoked. This is useful when a merchant wants to trigger a specific action when a purchase is reinstated, but not necessarily when it is first created. A great example of this is a welcome email. Typically, you only want to send a welcome email the first time someone purchases a product, not when it is reinstated after being revoked. Merchants cannot manually invoke a purchase tied to a canceled subscription. Instead, they must have the customer make a new purchase to create a new subscription. To simplify, standardize, and ensure reliability in integrating with purchases, we offer a base class that you can extend for your integration. This class and the associated interfaces require you to provide essential details and methods to override for handling various purchase model lifecycle events. In most cases, you can complete the entire integration within a single class or file. Extending this class also enables SureCart to display your integration in different user interfaces, allowing merchants to select it from a list of available integrations.Example: Creating A User Role Switcher
In this example, we will create a user role switcher integration. In this integration, when a purchase is created or invoked, we will assign a specific role to the customer. When a purchase is revoked, we will remove that role.SureCart already includes this integration by default. We’re providing this as
an example so you can understand how to build your own integrations if needed.
1
Extend IntegrationService
First, let’s extend the IntegrationService class.
2
Set the integration details
Next, let’s provide the details of our integration.
3
Populate the integration item chooser
To ensure that the integration is displayed in the integration chooser, two functions must be provided:
getItems and getItem. These functions are essential for populating the integration item chooser and enabling SureCart to retrieve individual items.Items can be thought of as individual records. In this example, an item represents a role. If you were to build an integration with a specific post type, for example, the item would be a list of your post type posts.Individual items are expected to be in this format:GetItems
Let’s create agetItems method and map all user roles to an array of item choices. As with the above, we want the savable id to be the role name, and the label to be the role display name.The search term is also passed, so you can make sure you are querying relevant results. Since we return all roles, we do not need this term, but it would be helpful for querying posts, for example.GetItem
The IntegrationInterface requires agetItem function. This function should return a single item choice, which is a single array in the item format noted above. In our case, we expect the id to be the role name, as that is what we defined in the getItems method.4
Change the role on Purchase lifecycle events
Next, we’ll implement the required functions for the This code can be further simplified for better readability and maintainability, as shown in the complete example below. However, the provided code gives you a basic idea of how to implement purchase syncing.There are also other optional methods for handling specific purchase changes. For instance, if you want to modify something when the purchase quantity changes, you can use the If you want to perform specific actions when a purchase’s product changes, such as when a subscription plan changes, you can utilize the
PurchaseSyncInterface. These functions are run when a purchase lifecycle event takes place and will allow us to modify the user’s role.The parameter $integration contains an integration_id attribute. This is the same id that you’ve set above in the getItem and getItems methods.onPurchaseQuantityUpdated method:Quantity Changed
onPurchaseProductAdded and onPurchaseProductRemoved methods. If you don’t define these methods, by default, the onPurchaseCreated function and onPurchaseRevoked function will be called when a purchase is added or removed, respectively.Product Added or Removed
5
Bootstrap the integration
The final step in integrating your custom purchase syncing logic is to bootstrap your integration. This involves creating a new instance of your integration class and calling the bootstrap function to initialize it.