Receive WhatsApp Payments via Payments Gateway
Last updated
Last updated
The Payments API feature is available only for Indian businesses using the 360dialog WhatsApp Business API with phone numbers only from India. Review WhatsApp Business Compliance for India.
This feature is now available to all Indian businesses. If the account is in high or medium tiers, admins or finance editors users will have direct access to the Payment Gateway page and can manage payment settings in Meta Business Manager. If you have any trouble using this feature, please reach out to our Support Team.
Currently, customers browse business catalogs, add products to cart, and send orders with Meta's set of commerce messaging solutions, which includes Single Product Message, Multi Product Message, and Product Detail Page. With the Payments API, businesses can send customers a bill, so the customer can complete their order by paying the business without having to leave WhatsApp.
First, the business composes and sends an order_details
message. An order_details
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 ID is used throughout the flow to track the order.
Once the message is sent, the business waits for a payment status update via webhooks. Businesses get notified when the payment status changes, but they must not solely rely on these webhook notifications due to security reasons. WhatsApp also provides a payment lookup API that can be used to retrieve the payment statuses directly anytime.
Please note that neither 360dialog nor WhatsApp supports payment reconciliations.
You must reconcile the payment with the business payment service provider using the respective order reference_id.
In the WhatsApp Messenger App, the purchase flow has the following steps:
Customers send an order with selected products to the business either through simple text messages or using other interactive messages such as Single Product Message, Multi Product Message, and Product Detail.
Once the business receives the order, they send an order_details
message to the user. When the user taps on Review and Pay, they will see details about the order and total amount to be paid.
When the user taps the Continue button, they are able to choose to pay natively on WhatsApp or any other UPI app.
Once the payment has been confirmed by your payment gateway (PG) or payment service provider, the business can start processing the order.
Businesses can then send an order_status
message to the consumer informing them about the status of the order. Each message will result in a message bubble (as shown above) that refers to the original order details message and also updates the status displayed on the order details page.
To receive payments on WhatsApp, businesses must add a payment configuration to the corresponding WhatsApp Business Account. A payment configuration allows you to link a payment gateway account to WhatsApp. Each payment configuration is associated with a unique name. As part of the order_details
message, you can specify the payment configuration to use for a specific checkout. WhatsApp will then generate a checkout flow using the associated payment gateway account.
Businesses can use the 'Direct pay methods' page and under 'India' in WhatsApp Business Manager.
Once the user enters the details, Meta redirects them to the payment gateway website to enter their credentials and link their account with WhatsApp as shown below.
In case of the OBO WhatsApp Business Accounts, 360dialog can enter the payment configuration details and generate a link URL. This link URL will be shared, which will allow you to log into the payment gateway account and connect it with WhatsApp.
For this, please reach out to our support team.
After linking the payment account, you must integrate with the Payments APIs below. This will allow you to send an order_details
message to customers with the payment configuration to receive payments.
The steps outlined below assume that the business already knows what the user is interested in through earlier conversations. The Payments API is a standalone API and hence can work with various messages such as List Messages, Reply Buttons, Single or Multi-Product Messages.
The following sequence diagram demonstrates the typical integration flow for Payments API. The steps highlighted in green are the key integration steps.
To send an order_details
message, businesses must assemble an interactive object of type order_details
with the following components:
We now have support for partners and merchants to pass notes
, receipt
and udf
fileds in Order Details message and receive this data back in payment signals. Here we will take a look at merchants can pass notes, receipt fields for Razorpay and UDF for PayU PGs.
The parameters
value is a stringified JSON object.
By the end, the interactive object should look something like this for a catalog-based integration:
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:
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
.
These are parameters common to Cloud API message types
If you are using On-Premise API, remember that it is being discontinued by Meta. No new signups will be allowed with this type of integration from May 15, 2024.
Numbers registered before this date will still be supported, but should start planning a change of hosting type as soon as possible.
These are parameters common to On-Premise message types.
Make a POST call to the /messages
endpoint with the JSON object you have assembled. If your message is sent successfully, you get the following response:
For all errors that can be returned and guidance on how to handle them, see WhatsApp Cloud API, Error Codes.
For all errors that can be returned and guidance on how to handle them, see Errors while Messaging.
Product Experience
The customer receives an order_details
message similar to the one below (left). When they click on "Review and Pay", it opens up the order details screen as shown below (middle).
Customer can then pay for their order using "Continue" button that opens up a bottom sheet with the payment options (right).
Businesses receive updates via WhatsApp webhooks when the status of the user-initiated transaction changes in a status of type "payment". It contains the following fields:
Here is an example status webhook of type payment
:
After receiving the payment status change notification, or at any time, the business can look up the status of the payment or transaction. To do that, businesses must make a GET
call to /payments/{payment-config-id}
/{reference_ID
}.
Businesses should expect a response in the same HTTP session (not in a webhook notification). payment_configuration
and reference_id
must be the same as that provided in the initial order_details
message.
A response can return the following values:
A successful response looks like this:
In the case of any errors, this is the response:
For all errors that can be returned and guidance on how to handle them, see Errors while Messaging
Businesses must send updates to their order using the order_status
message instead of text messages since the latest status of an order displayed on the order-details-page is only based on order_status
messages.
To notify the customer with updates to an order, you can send an interactive
message of type order_status
as shown below:
The following table describes the fields in the order_status
interactive message:
The parameters
object contains the following fields:
order_status
message introduces two new errors that are summarized below.
Product Experience
Customers receive each order_status
update as a separate message in their chat thread, that references their original order_details
message as shown below (left). The order details page always displays the latest valid status communicated to the customer using the order_status
message as shown below (right).
Supported Order Status and Transitions
Currently we support the following order status values:
Order status transitions are restricted for consistency of consumer experience. Allowed status transitions are summarized below:
Initial status of an order is always pending
, which is sent in order_details
message.
canceled
and completed
are terminal status and cannot be updated to any other status.
pending
can transition to any of the other statuses including processing
, shipped
, partially-shipped
.
processing
, shipped
and partially-shipped
are equivalent statuses and can transition between one another or to one of the terminal statuses.
Upon sending an order_status
message with an invalid transition, you will receive an error webhook with the error code 2046
and message "New order status was not correctly transitioned."
Canceling an Order
An order can be canceled
by sending an order_status
message with the status canceled
.
The customer cannot pay for an order that is canceled. The customer receives an order_status
message (left) and order details page is updated to show that the order is canceled and the "Secure Checkout" button removed (right). The optional text shown below "Order canceled" on the order details page can be specified using the description
field in the order_status
message.
An order can be canceled only if the user has not already paid for the order. If the user has paid and you send an order_status
message with canceled
status, you will receive an error webhook with error code 2047
and message "Could not change order status to 'canceled'".
Please note that neither 360dialog nor WhatsApp supports payment reconciliations. Businesses should use their payment gateway account to reconcile the payments using the reference_id
provided in the order_details
messages and the id
of the transactions returned as part of the payment lookup query.
Review our WABA Security documentation.
Businesses should not rely solely on the status of the transaction provided in the webhook and must use payment lookup API to retrieve the statuses directly from WhatsApp.
To ensure secure financial processing, payment configurations such as the business’ VPA shared by all WhatsApp phone numbers must belong to the same Business Manager account. If you wish to separate payments for different phone numbers, then additional Business Manager Accounts must be created.
Businesses must always sanitize/validate the data in the API responses or webhooks to protect against SSRF attacks.
Object | Description |
---|---|
Object | Description |
---|---|
Object | Description |
---|---|
Object | Description |
---|---|
Object | Description |
---|---|
Object | Description |
---|---|
Field | Description |
---|---|
Status | Description |
---|---|
Object | Description |
---|---|
Value | Description |
---|---|
Error Code | Description |
---|---|
Value | Description |
---|---|