Receive WhatsApp Payments via Payment Links
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 in with our set of commerce messaging solutions, which includes Single Product Message, Multi Product Message, and Product Detail Page.
Businesses can enable customers to pay for their orders using all the UPI Apps installed on their devices via WhatsApp. Businesses can send customers invoices (order_details
) messages, then get notified about payment status updates via webhook notifications from Payment Gateway.
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 a payment signal for an order, business should relay this payment signal to the consumer client through interactive order status(order_status
) message.
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 customer app, the purchase flow has the following steps:
Customer sends an order with selected products to the business or business identifies the products that the customer has shown interest to purchase.
After receiving the order or identifying the product, if a business accepts payment methods other than UPI, such as credit cards and payment wallets, etc. then business will send a message to the user to get their preferred payment method for the order.
When consumers want to pay using other payment method option, the business should generate the payment link by calling Payment Gateway by providing the unique "reference-id" and other information like amount, validity etc, then business can use the generated payment link to construct the order details message and send to the consumer.
When the consumer taps the Pay now/continue button, consumer will be redirected to the payment link within specially designed In-App browser to present with the list of supported payment options such as credit card, debit card, wallet or UPI apps. Consumers can choose any one of the payment option to pay for the order.
The following is a sample payment link redirect within In-App Browser accepting various payment methods like credit, debit, wallet and UPI apps.
Once the payment is complete, the business will receive a notification from Payment Gateway and the business needs to send order status updates to the consumer client notifying consumers about the progress on their order, this will update the order details message CTAs, Order details screen and Order status. The order status should contain the matching "reference-id" of order details.
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:
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:
type
object
Required.
Must be "order_details
".
header
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,
body
object
Required.
An object with the body of the message. The object contains the following field:
text
string
Required if body
is present. The content of the message. Emojis and markdown are supported. Maximum length is 1024 characters
footer
object
Optional.
An object with the footer of the message. The object contains the following fields:
text
string
Required if footer
is present. The footer content. Emojis, markdown, and links are supported. Maximum length is 60 characters
action
object
Required.
An action object you want the user to perform after reading the message. This action object contains the following fields:
name
string
Required. Must be "review_and_pay"
parameters
object
See Parameters Object for information
reference_id
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 reference_id
must be unique for each order_details
message for the same business. If the partner would like to send multiple order_details messages for the same order, invoice, etc. it is recommended to include a sequence number in the reference_id
(for example, -) to ensure reference_id
uniqueness.
type
object
Required.
The type of goods being paid for in this order. Current supported options are digital-goods
and physical-goods
beneficiaries
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.
name
string
Required. Name of the individual or business receiving the physical goods. Cannot exceed 200 characters
address_line1
string
Required. Shipping address (Door/Tower Number, Street Name etc.). Cannot exceed 100 characters
address_line2
string
Optional. Shipping address (Landmark, Area, etc.). Cannot exceed 100 characters
city
string
Optional. Name of the city.
state
string
Optional. Name of the state.
country
string
Required. Must be "India".
postal_code
string
Required. 6-digit zipcode of shipping address.
payment_type
Required.
Must be "upi".
payment_settings
Required. See Payment Settings Object for more details.
currency
Required.
The currency for this order. Currently the only supported value is INR
.
total_amount
object
Required.
The total_amount
object contains the following fields:
offset
integer
Required. Must be 100
for INR
.
value
integer
Required. Positive integer representing the amount value multiplied by offset. For example, ₹12.34 has value 1234.
total_amount.value
must be equal to order.subtotal.value
+ order.tax.value
+ order.shipping.value
- order.discount.value
.
order
object
Required.
See order object for more information.
type
string
Required. Must be payment_link
.
payment_link
object
Required. Refer Payment Link Object for more information.
uri
string
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.
Order Object
status
string
Required.
Only supported value in the order_details
message is pending
.
In an order_status
message, status
can be: pending
, captured
, or failed
.
items
object
Required.
An object with the list of items for this order, containing the following fields:
retailer_id
string
Required. Unique identifier for an item in the order.
name
string
Required. The item’s name to be displayed to the user. Cannot exceed 60 characters
amount
amount object with value and offset -- refer total amount field above
Required. The price per item
sale_amount
amount object
Optional. The discounted price per item. This should be less than the original amount. If included, this field is used to calculate the subtotal amount
quantity
integer
Required. The number of items in this order, this field cannot be decimal has to be integer.
country_of_origin
string
Required if catalog_id
is not present. The country of origin of the product
importer_name
string
Required if catalog_id
is not present. Name of the importer company
importer_adress
string
Required if catalog_id
is not present. Address of importer company
subtotal
object
Required.
The value must be equal to sum of order.amount.value
* order.amount.quantity
. Refer to total_amount
description for explanation of offset
and value
fields
The following fields are part of the subtotal
object:
offset
integer
Required. Must be 100
for INR
value
integer
Required. Positive integer representing the amount value multiplied by offset. For example, ₹12.34 has value 1234
tax
object
Required.
The tax information for this order which contains the following fields:
offset
integer
Required. Must be 100
for INR
value
integer
Required. Positive integer representing the amount value multiplied by offset. For example, ₹12.34 has value 1234
description
string
Optional. Max character limit is 60 characters
shipping
object
Optional.
The shipping cost of the order. The object contains the following fields:
offset
integer
Required. Must be 100
for INR
value
integer
Required. Positive integer representing the amount value multiplied by offset. For example, ₹12.34 has value 1234
description
string
Optional. Max character limit is 60 characters
discount
object
Optional.
The discount for the order. The object contains the following fields:
offset
integer
Required. Must be 100
for INR
value
integer
Required. Positive integer representing the amount value multiplied by offset. For example, ₹12.34 has value 1234
description
string
Optional. Max character limit is 60 characters
discount_program_name
string
Optional. Text used for defining incentivised orders. If order is incentivised, the merchant needs to define this information. Max character limit is 60 characters
catalog_id
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: country_of_origin
, importer_name
, and importer_address
expiration
object
Optional.
Expiration for that order. Business must define the following fields inside this object:
timestamp
string – UTC timestamp in seconds of time when order should expire. Minimum threshold is 300 seconds
description
string – Text explanation for expiration. Max character limit is 120 characters
By the end, the interactive object should look something like this for a catalog-based integration:
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
.
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:
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:
pending
User has not successfully paid yet
processing
User payment authorized, merchant/partner is fulfilling the order, performing service, etc.
partially-shipped
A portion of the products in the order have been shipped by the merchant
shipped
All the products in the order have been shipped by the merchant
completed
The order is completed and no further action is expected from the user or the partner/merchant
canceled
The partner/merchant would like to cancel the order_details
message for the order/invoice. The status update will fail if there is already a successful
or pending
payment for this order_details
message
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.
The following table describes the returned values:
reference_id
The ID provided by the partner in the order_details
message
status
The new order status
description
Optional text for sharing status related information in order_details
. Could be useful while sending cancellation. Max character limit is 120 characters
Please note that neither 360dialog nor WhatsApp supports payment reconciliations. Businesses should use their bank statements to reconcile the payments using the reference_id
provided in the order_details
messages.