Skip to main content

Complete the Checkout

Once the widget is loaded, the customer will be able to access and complete the checkout process to split the payment. Below are the steps of the process, where all interaction with the customer happens within the Checkout widget.

Checkout process​

  1. Payment plan: The customer reviews the payment plan (for the amount and financial product selected in the POST Create Order) and, if available, select the installment amount (term) that most interests her.
  2. Personal information:
    1. The customer reviews her data (pre-filled in the form) and can edit or complete those fields that are empty and actually required by the lender(s).
    2. The customer receives an SMS with a key (OTP) that must be introduced to verify her mobile phone.
  3. First payment:
    1. The customer reviews the payment plan and enters their card details to continue with the payment of the first installment.
    2. The customer completes the SCA of her bank (optional) and the lender charges the first installment on her card.
  4. Confirm the order or put it on hold (only step that requires action on your side):
    1. The lender notifies Nemuru about the order being approved or placed on hold.
    2. Nemuru notifies you by sending a POST notification to let you know about the lender's decision and you should take action accordingly, as explained next.
info

The notification_url is indicated by you in the POST Create Order.

Order status​

As previously seen, during the checkout process, the order is subject to change its status. For simplicity, we have separated the status diagram into two different diagrams: one with the on_hold status (manual review) and another without it (instant approval).

On hold

By default, BNPL lenders will approve the order instantly, and you should NOT consider the on_hold status in the following sections. In case the lender needs to review the order manually before approving it, Nemuru's team will inform you about it. Otherwise, you can skip the on_hold status.

The following sections display all possible statusses and their transitions for both scenarios.

Without on_hold (instant approval)​

The order starts with the initial status when you send the cart to Nemuru.

Before completing the checkout process, the customer could have abandoned it, which would lead to the desisted status. Additionally, the order could have expired, leading to the expired status.

Once the customer completes the checkout process, the order will go through requested status.

Then, the lender will review the order and decide whether to approve it or not. This is the "Confirmation flow", pointed out by a yellow circle in the diagram, and explained in depth in scenarios 1 - 5 in the following Confirmation flow section. Nemuru will notify you about the lender's decision through a POST notification.

  • If the order is denied by the lender (you will receive status denied), and the order will transition to denied.
  • If the order is approved by the lender (you will receive status approved), and you will have to accept it or reject it.
    • If you reject it, the order will be cancelled.
    • If you accept it, the order will transition to confirmed if autoconfirm is enabled –otherwise you will have to manually confirm it (PUT Confirm Order). We recommend you to confirm the order automatically, by following the autoconfirm instructions in the scenario 3.

Once confirmed, it will be necessary to capture the payment (shipping the product or providing the service) and the order will transition to captured. The order can be captured automatically by using the autoshipping in each line item of the cart, informed upon order creation. When captured, the lender will include the order's total amount in the following disbursement.

The order status will be paid when the lender has actually disbursed the total amount of the order. In other words, the funds will be transferred to your account (time to get the funds in your account will depend on the lender).

If the order is fully refunded, the status will be cancelled.

alt text

With on_hold (manual review)​

On hold

By default, BNPL lenders will approve the order instantly, and you should consider the previous section instead. In case the lender needs to review the order manually before approving it, Nemuru's team will inform you about it. In that case, you can follow the instructions in this section.

The order starts with the initial status when you send the cart to Nemuru.

Before completing the checkout process, the customer could have abandoned it, which would lead to the desisted status. Additionally, the order could have expired, leading to the expired status.

Once the customer completes the checkout process, the order will go through requested status.

Then, the lender will review the order and decide whether to approve it, place it on hold for manual review, or deny it. This is the "Confirmation flow", pointed out by a yellow circle in the diagram, and explained in depth in scenarios 1 - 9 in the following Confirmation flow section. Nemuru will notify you about the lender's decision through a POST notification.

  • If the order is denied by the lender (you will receive status denied), and the order will transition to denied.
  • If the order is placed on hold by the lender (you will receive status on_hold), and you will have to place it on hold too.
    • If you place it on hold, the order will transition to on_hold.
    • If you reject it, the order will be cancelled.
  • If the order is approved by the lender (you will receive status approved), and you will have to accept it or reject it.
    • If you reject it, the order will be cancelled.
    • If you accept it, the order will transition to confirmed if autoconfirm is enabled –otherwise you will have to manually confirm it (PUT Confirm Order). We recommend you to confirm the order automatically, by following the autoconfirm instructions in the scenario 3.

If the order has been successfully placed on hold, the lender will manually review it and decide whether to approve it or not (pointed out by the second yellow circle in the diagram). Nemuru will notify you about the lender's final decision through a POST notification.

  • If the order is denied by the lender (you will receive status denied), and the order will transition to denied.
  • If the order is approved by the lender (you will receive status approved), and you will have to accept it or reject it.
    • If you reject it, the order will be cancelled.
    • If you accept it, the order will transition to confirmed if autoconfirm is enabled –otherwise you will have to manually confirm it (PUT Confirm Order). We recommend you to confirm the order automatically, by following the autoconfirm instructions in the scenario 3.

Once confirmed, it will be necessary to capture the payment (shipping the product or providing the service) and the order will transition to captured. When captured, the lender will include the order's total amount in the following disbursement.

The order status will be paid when the lender has actually disbursed the total amount of the order. In other words, the funds will be transferred to your account (time to get the funds in your account will depend on the lender).

If the order is fully refunded, the status will be cancelled.

alt text

Confirmation flow​

As introduced before, the confirmation flow is the process that happens after the customer completes the checkout process. This process is the communication between Nemuru, the lender, and you (the merchant).

The POST notification is employed by Nemuru to let you know about the lender's decision. This is the starting point of the confirmation flow. Throughout the duration of the confirmation flow (that happens behind the scenes), the Checkout widget will display a loading screen to prevent the customer from abandoning the process.

There are multiple confirmation flow scenarios. Depending on the lender's decision and your decision too, with regard to the order, the confirmation flow will be either one or another. Let's take a look at these different scenarios:

info

The on_hold status is used when the lender needs to review the order before approving it. This status is not mandatory and it's up to the lender to decide when to use it. Contact us to know if the lender you are working with uses this status. If you are not working with a lender that uses the on_hold status, you can skip the scenarios 6 - 9.

Order denied by the lender​

  1. 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

Order approved by the lender​

  1. The lender approved the Order and you (the merchant) confirm it

    (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.
    (3) The merchant sends a PUT Confirm Order request in order to confirm the order. The body of this request includes all the order payload.
    (4) Nemuru sends the order passed by the merchant to the lender, so the latter can validate and confirm it.
    (4R) The lender confirms the order to Nemuru.
    (3R) Nemuru responds to the request (3) with status 204, letting the merchant know that it has been confirmed by the lender.
    (2R) The merchant responds to the request (2) with status code 200.
    (5) 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.
    (5R) The merchant responds to the request (5) with status code 200.

    alt text

  2. 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 and { "autconfirm": true } within the body (to instruct Nemuru to auto-confirm the order with the lender).
    (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

  3. The lender approved the Order and you (the merchant) confirm it, but the cart has changed

    (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.
    (3) The merchant sends a PUT Confirm Order request in order to confirm the order. The body of this request includes all the order payload.
    (4) Nemuru sends the order passed by the merchant to the lender, so the latter can validate and confirm it.
    (4R) The lender rejects the order because the cart has changed (or other reasons).
    (3R) Nemuru responds to the request (3) with status 409 Conflict, letting the merchant know that it has been denied by the lender.
    (2R) The merchant responds to the request (2) with status code 200.
    (5) Nemuru notifies 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.
    (5R) The merchant responds to the request (5) with status code 200.

    alt text

  4. The lender approved the Order but you (the merchant) reject it

    (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 410, indicating that the order is cancelled.
    (3) Nemuru sends the cancellation request to the lender, so the latter can cancel it as well.
    (3R) The lender confirms the order cancellation to Nemuru.
    (4) Nemuru notifies the merchant that the order is cancelled (POST notification). The body of the request includes the order_id and additional parameters passed when creating the order, plus the status cancelled value.
    (4R) The merchant responds to the request (4) with status code 200.

    alt text

Order placed on hold by the lender​

info

If you are not working with a lender that uses the on_hold status, you can skip the scenarios 6 - 9. Contact us to know if the lender you are working with uses this status.

  1. The lender placed the Order on hold and you (the merchant) place it on hold too

    (1) Nemuru receives a notification from the lender indicating the order needs review and is placed on hold temporarily.
    (2) Nemuru notifies you (the merchant) that the order is on hold 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 on_hold value.
    (3) The merchant sends a PUT Confirm Order request in order to confirm that the order is placed on hold. The body of this request includes all the order payload.
    (4) Nemuru sends the order passed by the merchant to the lender, so the latter can validate and confirm it.
    (4R) The lender confirms the order being placed on hold to Nemuru.
    (3R) Nemuru responds to the request (3) with status 204, letting the merchant know that placing the order on hold has been confirmed by the lender.
    (2R) The merchant responds to the request (2) with status code 200.

    alt text

  2. The lender placed the Order on hold and you (the merchant) place it on hold too (autoconfirm)

    (1) Nemuru receives a notification from the lender indicating the order needs review and is placed on hold temporarily.
    (2) Nemuru notifies you (the merchant) that the order is on hold 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 on_hold value.
    (2R) The merchant responds to the request (2) with status code 200 and { "autconfirm": true } within the body (to instruct Nemuru to auto-confirm the order with the lender).
    (3) Nemuru sends the stored order to the lender, so the latter can validate and confirm it.
    (3R) The lender confirms the order being placed on hold to Nemuru.

    alt text

  3. The lender placed the Order on hold and you (the merchant) place it on hold too, but the cart has changed

    (1) Nemuru receives a notification from the lender indicating the order needs review and is placed on hold temporarily.
    (2) Nemuru notifies you (the merchant) that the order is on hold 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 on_hold value.
    (3) The merchant sends a PUT Confirm Order request in order to confirm that the order is placed on hold. The body of this request includes all the order payload.
    (4) Nemuru sends the order passed by the merchant to the lender, so the latter can validate and confirm it.
    (4R) The lender rejects the order because the cart has changed (or other reasons).
    (3R) Nemuru responds to the request (3) with status 409 Conflict, letting the merchant know that it has been denied by the lender.
    (2R) The merchant responds to the request (2) with status code 200.
    (5) Nemuru notifies 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.
    (5R) The merchant responds to the request (5) with status code 200.

    alt text

  4. The lender placed the Order on hold but you (the merchant) reject it

    (1) Nemuru receives a notification from the lender indicating the order needs review and is placed on hold temporarily.
    (2) Nemuru notifies you (the merchant) that the order is on hold 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 on_hold value.
    (2R) The merchant responds to the request (2) with status code 410, indicating that the order is cancelled.
    (3) Nemuru sends the cancellation request to the lender, so the latter can cancel it as well.
    (3R) The lender confirms the order cancellation to Nemuru.
    (4) Nemuru notifies the merchant that the order is cancelled (POST notification). The body of the request includes the order_id and additional parameters passed when creating the order, plus the status cancelled value.
    (4R) The merchant responds to the request (4) with status code 200.

    alt text

Requests​

POST notification​

Some lenders might approve the order and wait for you to send the cart again to validate it hasn't changed (much). This is done for security reasons.

Autoconfirm

Depending on specific circumstances (you are able to block the cart on your site, commercial agreements with the lender, etc), you can instruct us to auto-confirm the order with the lender. In such scenario, we will send the same cart that you initially sent to us (through POST Create Order) and thus ensure the lender's validation goes OK. This removes you from having to send the Order payload again (explained in detail next).

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 Order"41c325c0-161c-43d6-bb4f-65f6b50b9ba0"
order_reference_1stringYour ID of the order (merchant-side), included by you in the POST Create Order"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 manual 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

Response​

Depending on the scenario, your response to Nemuru will vary. The next section lays out the different scenarios and the sequence diagrams to better understand the communication flow between all the systems.

PUT Confirm / place on hold the Order​

Request​

PUT /order/{order_id}/
Authorization: Bearer access_token
Content-Type: application/json
tip

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

{
  // highlight-next-line
  "status": "confirmed",
  "product": "instalments",
  "merchant": {
    "order_reference_1": "7QuHQ5WVQQqyWVPW",
    "order_reference_2": "14-922-1039",
    "notification_url": "https://nemuru.free.beeceptor.com/callback",
    "notification_auth": {
      "authorization_header": "Basic bG9sOnNlY3VyZQ==",
      "content_type": "application/json"
    },
    "notification_additional_payload": {
      "cart": "h12837hg="
    }
  },
  "customer": {
    "first_name": "Alba",
    "last_name": "Martinez Laguna",
    "title": "ms",
    "email": "alba.martinez@gmail.com",
    "phone_number": "+34659723349",
    "document_number": "55593310X",
    "document_expiration_date": "2024-02-27T12:00:00+01:00",
    "birth_date": "1982-11-03T12:00:00+01:00",
    "nationality": "ESP",
    "logged_in": false,
    "locale": "es-ES",
    "ip_address": "192.0.2.146",
    "user_agent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"
  },
  "cart": {
    "reference": "76t7y7sau8y398y",
    "total_price_with_tax": 1500,
    "currency": "EUR",
    "items": [
      {
        "article": {
          "name": "KIVIK 3-seat sofa",
          "type": "product",
          "category": "physical",
          "reference": "4912345678904",
          "unit_price_with_tax": 875,
          "description": "3-seat sofa, with chaise longue/Hillared anthracite",
          "brand": "the-ikea-brand",
          "mpn": "AD6654412-334.22",
          "url": "https://www.ikea.com/ie/en/p/kivik-3-seat-sofa-with-chaise-longue-hillared-anthracite-s89193665/",
          "image_url": "https://www.ikea.com/ie/en/p/kivik-3-seat-sofa-with-chaise-longue-hillared-anthracite-s89193665/"
        },
        "units": 1,
        "total_discount": 0,
        "total_price_with_tax": 875,
        "auto_shipping": true
      },
      {
        "article": {
          "name": "EKEDALEN / EKEDALEN Bar table and 4 bar stools",
          "type": "product",
          "category": "physical",
          "reference": "5930423178914",
          "unit_price_with_tax": 625,
          "description": "Bar table and 4 bar stools, white/Ramna light grey120 cm"
        },
        "units": 1,
        "total_discount": 0,
        "total_price_with_tax": 625
      }
    ]
  },
  "shipping": {
    "name": "SEUR24",
    "method": "home",
    "first_name": "Alba",
    "last_name": "Martinez",
    "company": "EL DON TRESILLO CATALAN SL",
    "email": "alba.martinez@gmail.com",
    "phone_number": "+34659723349",
    "address": {
      "street_address": "Pl. de Pau Vila, 1",
      "street_address_2": "Planta 1A",
      "postal_code": "08003",
      "city": "Barcelona",
      "country": "ESP"
    }
  },
  "billing": {
    "first_name": "Alba",
    "last_name": "Martinez",
    "email": "alba.martinez@gmail.com",
    "phone_number": "+34659723349",
    "company": "EL DON TRESILLO CATALAN SL",
    "corporate_id_number": "A35628221",
    "address": {
      "street_address": "Pl. de Pau Vila, 1",
      "street_address_2": "Planta 1A",
      "postal_code": "08003",
      "city": "Barcelona",
      "country": "ESP"
    }
  }
}
  • Same as POST Create Order
  • Additionally add the status field:
    • confirmed when the merchant receives an approved notification from Nemuru and proceeds to confirm the order
    • on_hold when the merchant receives an on_hold notification by Nemuru and proceeds to place the order on_hold