We are sunsetting On-Premises API. Refer to our On-Premises API Sunset document for details, and to learn how to migrate to our next-generation Cloud API.
Your businesses can enable customers to pay for their orders by bringing in all the payment methods supported on your platform to WhatsApp. Businesses can send customers invoice(order_details
) messages, then get notified about payment status updates via webhook notifications from Payment Gateway.
This feature is not publicly available yet. Please reach out to the Meta Business Engineering teams to know more.
Currently, customers browse business catalogs, add products to cart, and send orders in with our set of commerce messaging solutions, which includes Single Product Message, Multi Product Message, and Product Detail Page.
With the WhatsApp Messaging API, businesses can send customers a bill to complete the order with one of the supported payment instrument.
The business must send an order_details
message for the consumer to initiate payment. This type of message is a new type of interactive message, which always contains the same 4 main components: header, body, footer, and action. Inside the action component, the business includes all the information needed for the customer to complete their payment.
Each order_details
message contains a unique reference_id
provided by the business, and that unique number is used throughout the flow to track the order. This reference_id
is used to generate the payment link from Payment Gateway.
Once the message is sent, the business waits for a payment or transaction status updates directly from Payment Gateway. Upon receiving payment signal for an order, business should relay this payment signal to consumer client through interactive order status(order_status
) message.
Updating user about the payment signal is important as this message updates the order details message and order details view for the consumer reflecting the order confirmation from merchant. This is shown with an example in subsequent sections.
In the WhatsApp customer app, the purchase flow has the following steps:
The following is a sample payment link redirect within In-App Browser accepting various payment methods like credit, debit, wallet and UPI apps.
The steps outlined below assume that the business is about to send order details message to consumer client.
The following sequence diagram demonstrates the typical integration flow for WA Payments API:
Once the consumer has expressed their interest to purchase an item using payment link. Business needs to call payment gateway with necessary information like reference-id, amount and validity to generate the payment link. Following is a sample payment link:
https://rzp.io/i/rNiAagU8y
Business needs to use the same reference-id, amount and expiration in invoice(order_details
) interactive message.
To send an order_details
message, businesses must assemble an interactive object of type order_details
with the following components:
Object | Description |
---|---|
object | Required. Must be "order_details". |
object | Optional. Header content displayed on top of a message. If a header is not provided, the API uses an image of the first available product as the header |
object | Required. An object with the body of the message. The object contains the following field:
|
object | Optional. An object with the footer of the message. The object contains the following fields:
|
object | Required. An action object you want the user to perform after reading the message. This action object contains the following fields:
|
Object | Description |
---|---|
string | Required. Unique identifier for the order or invoice provided by the business. This cannot be an empty string and can only contain English letters, numbers, underscores, dashes, or dots, and should not exceed 35 characters. The |
object | Required. The type of goods being paid for in this order. Current supported options are |
array | Required for shipped physical-goods. An array of beneficiaries for this order. A beneficiary is an intended recipient for shipping the physical goods in the order. It contains the following fields: Beneficiary information isn't shown to users but is needed for legal and compliance reasons.
|
| Required. Must be "upi". |
| Required. See Payment Settings Object for more details. |
| Required. The currency for this order. Currently the only supported value is |
object | Required. The
|
object | Required. See order object for more information. |
Object | Description |
---|---|
| Required.
Must be |
| Required. Refer Payment Link Object for more information. |
Object | Description |
---|---|
| Required. A valid payment link generated through payment gateway. Generated payment links domains needs to be enabled to accept payments. Please reach out to the Meta Business Engineering teams to know more. |
Object | Description |
---|---|
string | Required. Only supported value in the In an |
object | Required. An object with the list of items for this order, containing the following fields:
|
object | Required. The value must be equal to sum of The following fields are part of the
|
object | Required. The tax information for this order which contains the following fields:
|
object | Optional. The shipping cost of the order. The object contains the following fields:
|
object | Optional. The discount for the order. The object contains the following fields:
|
object | Optional. Unique identifier of the Facebook catalog being used by the business. If you do not provide this field, you must provide the following fields inside the items object: |
object | Optional. Expiration for that order. Business must define the following fields inside this object:
|
The parameters
value is a stringified JSON object.
By the end, the interactive object should look something like this for a catalog-based integration:
{ "interactive": { "type": "order_details", "header": { "type": "image", "image": { "link": "http(s)://the-url", "provider": { "name": "provider-name" } } }, "body": { "text": "your-text-body-content" }, "footer": { "text": "your-text-footer-content" }, "action": { "name": "review_and_pay", "parameters": { "reference_id": "reference-id-value", "type": "digital-goods", "payment_type": "upi", "payment_settings": [ { "type": "payment_link", "payment_link": { "uri": "https://the-payment-link" } } ], "currency": "INR", "total_amount": { "value": 21000, "offset": 100 }, "order": { "status": "pending", "catalog_id": "the-catalog_id", "expiration": { "timestamp": "utc_timestamp_in_seconds", "description": "cancellation-explanation" }, "items": [ { "retailer_id": "1234567", "name": "Product name, for example bread", "amount": { "value": 10000, "offset": 100 }, "quantity": 1, "sale_amount": { "value": 100, "offset": 100 } } ], "subtotal": { "value": 20000, "offset": 100 }, "tax": { "value": 1000, "offset": 100, "description": "optional_text" }, "shipping": { "value": 1000, "offset": 100, "description": "optional_text" }, "discount": { "value": 1000, "offset": 100, "description": "optional_text", "discount_program_name": "optional_text" } } } } } }
The parameters
value is a stringified JSON object.
For a non-catalog based integration i.e. when catalog-id is not present, an example payload looks as follows:
{ "interactive": { "type": "order_details", "header": { "type": "image", "image": { "id": "your-media-id" } }, "body": { "text": "your-text-body-content" }, "footer": { "text": "your-text-footer-content" }, "action": { "name": "review_and_pay", "parameters": { "reference_id": "reference-id-value", "type": "digital-goods", "payment_type": "upi", "payment_settings": [ { "type": "payment_link", "payment_link": { "uri": "https://the-payment-link" } } ], "currency": "INR", "total_amount": { "value": 21000, "offset": 100 }, "order": { "status": "pending", "expiration": { "timestamp": "utc_timestamp_in_seconds", "description": "cancellation-explanation" }, "items": [ { "retailer_id": "1234567", "name": "Product name, for example bread", "amount": { "value": 10000, "offset": 100 }, "quantity": 1, "sale_amount": { "value": 100, "offset": 100 }, "country_of_origin": "country-of-origin", "importer_name": "name-of-importer-business", "importer_address": { "address_line1": "B8/733 nand nagri", "address_line2": "police station", "city": "East Delhi", "zone_code": "DL", "postal_code": "110093", "country_code": "IN" } }, { "retailer_id": "14325", "name": "Product name, for example bread", "amount": { "value": 10000, "offset": 100 }, "quantity": 1, "sale_amount": { "value": 100, "offset": 100 }, "country_of_origin": "country-of-origin", "importer_name": "name-of-importer-business", "importer_address": { "address_line1": "B8/733 nand nagri", "address_line2": "police station", "city": "East Delhi", "zone_code": "DL", "postal_code": "110093", "country_code": "IN" } } ], "subtotal": { "value": 20000, "offset": 100 }, "tax": { "value": 1000, "offset": 100, "description": "optional_text" }, "shipping": { "value": 1000, "offset": 100, "description": "optional_text" }, "discount": { "value": 1000, "offset": 100, "description": "optional_text", "discount_program_name": "optional_text" } } } } } }
Once the interactive object is complete, append the other parameters that make a message: recipient_type
, to
, and type
. Remember to set the type
to interactive
.
{ "messaging_product": "whatsapp", "recipient_type": "individual", "to": "PHONE_NUMBER", "type": "interactive", "interactive": { // interactive object here } }
These are parameters common to all message types.
Make a POST call to the /messages
endpoint with the JSON
object you have assembled in steps 1 and 2. If your message is sent successfully, you get the following response.
{ "messages": [{ "id": "{message-id}" }] }
For all errors that can be returned and guidance on how to handle them, see WhatsApp On-Premises API, Errors.
Consumers can pay using WhatsApp payment method or using any UPI supported app that is installed on the device.
Businesses receive updates to the invoice via payment gateway webhooks, when the status of the user-initiated transaction changes. The unique identifier reference-id passed in order_details
message can be used to map the transaction to the consumer invoice or interactive order details message.
Upon receiving transaction signals from payment gateway through webhook, the business must update the order status to keep the user up to date. Currently we support the following order status values:
Value | Description |
---|---|
| User has not successfully paid yet |
| User payment authorized, merchant/partner is fulfilling the order, performing service, etc. |
| A portion of the products in the order have been shipped by the merchant |
| All the products in the order have been shipped by the merchant |
| The order is completed and no further action is expected from the user or the partner/merchant |
| The partner/merchant would like to cancel the |
Typically businesses update the order_status
using either the WhatsApp payment status change notifications or their own internal processes. To update order_status
, the partner sends an order_status
message to the user.
{ "recipient_type": "individual", "to": "whatsapp-id", "type": "interactive", "interactive": { "type": "order_status", "body": { "text": "your-text-body-content" }, "action": { "name": "review_order", "parameters": { "reference_id": "reference-id-value", "order": { "status": "processing | partially_shipped | shipped | completed | canceled", "description": "optional-text" } } } } }
The following table describes the returned values:
Value | Description |
---|---|
| The ID provided by the partner in the |
| The new order |
| Optional text for sharing status related information in |
For all errors that can be returned and guidance on how to handle them, see WhatsApp On-Premises API, Errors.
Merchant should always post this order-status message to consumer after reciving transaction updates for an order. As the order_details message and order details screen experience is tied to to the order status updates.
Businesses should use their bank statements to reconcile the payments using the reference_id
provided in the order_details
messages.
Ensure that order_status
message is send to consumer informing them about updates to an order after receiving transaction updates for an order.
Ensure the merchant is verified and WABA contact is marked with a verified check.
Verify the WABA is mapped to appropriate merchant initiated messaging tier(1k, 10k and 100k per day)
Merchant should list the customer support informatoin in the profile screen incase consumer wants to report any issues.