Quickpay

To get started, you need to create a Quickpay account. The Quickpay developer documentation provides all the resources you will need to optimize your payment integration. After getting an account, you will need:

• the API key to communicate with Quickpay servers
• the Merchant private key, per nature, it should be kept secret server-side. It will help verify the signature. This one is harder to find, and it is not an “API key”. You can find it under Settings > Merchant > Merchant Settings.

The Remix Run Furniture v2 boilerplate includes a full Quickpay integration, including a confirmation webhook.

On the checkout page, we render the Quickpay Link component, which does 3 things:

• makes the cart immutable
• creates a payment (server-to-server) and a Quickpay Link via the service layer
• renders the Link received

In this boilerplate, we decided to save the cart in our own service layer, so we push the order to Crystallize only when the payment is successful.

When Quickpay redirects the buyer to the shop, it goes to the `/order/cart/${cartId}` page. This page is actually waiting for the Cart to be saved as an order in Crystallize.

Indeed, while everything is happening, Quickpay will call the confirm payment endpoint. This works because we provide the callback URL to Quickpay upon Link creation. (see link above)

The endpoint, when the event concerns a `payment`:

• creates a customer in Crystallize, if one doesn’t exist yet.
• creates the order in Crystallize
• updates the cart from placed to paid, allowing the waiting page to update to the order confirmation

This boilerplate is also using our Node Service API Request Handlers that include 2 handlers to speed up your Quickpay integration.