All requests made by Bolt to your ecommerce Merchant API will be signed to ensure the authenticity of our requests. Your implementation should always verify the signature to make sure that it’s always Bolt calling your endpoint.
Bolt signs the payload and includes the HMAC signature in the request header X-Bolt-Hmac-Sha256. There are two ways to verify the payload with this signature.
When we talk about Bolt as a cohesive product experience, it’s important to understand all of the separate technical pieces that must be implemented to use Bolt with a custom cart platform. Those pieces are the following:
Now that we’ve covered the general components of Bolt in Part One of our Developer’s Guide, let’s dive into some specifics about how Bolt is communicating with your e-commerce platform. This article is a high-level framework tackling information found in our Bolt API Reference and Merchant API Reference.
If you are creating orders through the frontend rather than through the pre-auth endpoint, the order creation can be interrupted by a disrupted internet connection during checkout or by a customer’s browser crashing.
To handle orphaned transactions, make sure that the pending transaction hook is capable of converting an existing cart order_reference into an order.
|API Key||Used for calling Bolt API from your backend server|
|Publishable Key||Embedded on your website and used by Bolt to identify your website|
|Signing Secret||Used for signature verification on requests received from bolt|
You may choose to pass these error codes back to Bolt in Merchant API Responses to trigger appropriate messages for the shopper.
Authorization codes for payment processing vary depending on your Bolt Merchant Account setup. Bolt recommends reviewing authorization codes specific to your payment processor or gateway. External Resources Adyen Authorization Codes Braintree Authorization Codes Cybersource Authorization Codes NMI Authorization Codes Paypal Authorization Codes For WorldPay authorization codes, reach out to your customer success manager.
Admins and Developers can manage users of their Merchant Account from the Bolt Merchant Dashboard.
Webhook failure notifications provide you a means of tracking and resolving a crucial part of your Bolt integration. By default, Bolt does not notify merchants when a web hook failure occurs. Webhook failure email notifications must be activated on a per-user basis.
You can use the following card numbers to simulate scenarios in a sandbox. The type of test cards used vary depending on the processor or gateway set up with your merchant account.
|Reviewed and approved by Bolt||4111 1111 1111 1111|
|Reviewed and irreversibly rejected by Bolt||4457 0101 4000 0141||Shopper reaches order confirmation but is notified via email that there was an issue completing the order.|
|Reviewed and reversibly rejected by Bolt||4457 0102 0000 0247|
|Bolt rejection before authorization||4100 2003 1000 0002||Shopper receivesan error and does not proceed to order confirmation.|
|Place in review||4457 0002 0000 0008|
|Processor rejection||3743 133042 11118||Shopper receivesan error and does not proceed to order confirmation.|
Bolt provides developers the ability to leverage webhooks events to handle checkout events according to the business rules of your ecommerce store. Once configured, the Webhook endpoint will be used by Bolt to update your external server asynchronously on the occurrence of an event that you have subscribed to.