Skip to main content

Confirmation flow

The notification_url that you included in the Pay by link creation is used by Nemuru to let you know about the lender's decision.

During the confirmation flow, which occurs behind the scenes, the Checkout widget takes measures to prevent the customer from prematurely abandoning the process. While the confirmation flow is in progress, the Checkout widget will display a loading screen to maintain the customer's engagement and prevent any potential disruption or confusion.

There are two possible confirmation flow scenarios:

There's only one server-side request that you'll need to integrate to handle the confirmation flow.

Scenarios​

The lender approved the Order and you (the merchant) confirm it (autoconfirm)​

(1) Nemuru receives a notification from the lender indicating the order is approved.
(2) Nemuru notifies you (the merchant) that the order is approved by the lender (POST notification). The body of the request includes the order_id and additional parameters passed when creating the order, plus the status approved value.
(2R) The merchant responds to the request (2) with status code 200. In the header of the response, the merchant includes the following key-value set to indicate the order requires auto-confirm with lenders (autoconfirm: true).
(3) Nemuru sends the stored order to the lender, so the latter can validate and confirm it.
(3R) The lender confirms the order to Nemuru.
(4) Nemuru notifies the merchant that the order is confirmed by the lender (POST notification). The body of the request includes the order_id and additional parameters passed when creating the order, plus the status confirmed value.
(4R) The merchant responds to the request (4) with status code 200.

alt text

The lender denied the Order​

(1) Nemuru receives a notification from the lender indicating the order has been denied.
(2) Nemuru notifies you (the merchant) that the order is denied by the lender (POST notification). The body of the request includes the order_id and additional parameters passed when creating the order, plus the status denied value.
(2R) The merchant responds to the request (2) with status code 200.

alt text

POST notification​

Autoconfirm

You should simply instruct Nemuru to auto-confirm the order with the lender as the action is taking place in realtime at the store (most of the time). This removes you from having to send the Pay by link payload (cart, customer, merchant data) again.

Request​

POST notification_url                        // notification_url
Authorization: Basic bG9sOnNlY3VyZQ==        // notification_auth
Content-Type: application/json               // notification_auth
tip

Check the API Reference for all the details about this request.

{
  "order_id": "e60fb9d8-97d4-4653-bc7e-d49b203a6980",
  "order_reference_1": "76t7y7sau8y398y",
  "event": "order_status_changed",
  "triggered_at": "2022-03-31T09:42:15+00.00",
  "status": "approved",
  "cart": "h12837hg="
}

Parameter details:

FieldTypeDescriptionExample
order_idstringThe order_id returned by Nemuru in the POST Create Pay by link"41c325c0-161c-43d6-bb4f-65f6b50b9ba0"
order_reference_1stringYour ID of the order (merchant-side), included by you in the POST Create Pay by link"7QuHQ5WVQQqyWVPW"
eventstringEvent name"order_status_changed"
triggered_atstringTimestamp when the event was triggered. Format DATE_ATOM."2022-03-31T09:42:15+00.00"
statusstringThe Order status. Possible values are: ["approved", "confirmed", "on_hold", "denied", "cancelled", "expired", "desisted"]"approved"

This is the list of possible Order statusses (status):

  • on_hold: needs review by the lender
  • approved: approved by the lender, pending confirmation by you (the merchant)
  • confirmed: approved by the lender and confirmed by you (the merchant)
  • cancelled: approved by the lender but rejected by you (the merchant)
  • denied: denied by the lender
  • expired: the checkout is expired
  • desisted: the customer abandons the checkout process