Table of Contents

Out of scope

• Saving the Card brand used for Card at home payments for future reports. This information is not saved today.

Backend

Architecture AS-IS

Image Removed

Sequence diagram (WIP)

Image Removed

intl-whitelabel-app

The app has two possible backend services: intl-whitelabel-graphql or intl-fulfillment-service. The ENABLE FULFILLMENT FT controls which service is used. Today, BK-PT is using whitelabel graphql, but BK-ES is using fulfillment service, for Dev environments.

intl-whitelabel-graphql

After saving the order in DynamoDB, it is processed using intl-packages/fulfilment.

intl-packages/fulfilment

After receiving message to commit the order, the package will dispatch it to the appropiate POS Vendor and sends a message to SQS timeout queue. Here, the only payment validation check is for wrong order status and should not require changes to work with card payments at home.

    if (isPaymentRequired) {
      // order must be in payment successful or payment required state to proceed
      if (
        status !== RbiOrderStatus.PAYMENT_SUCCESSFUL &&
        status !== RbiOrderStatus.PAYMENT_REQUIRED
      ) {
        throw new UnpaidCommitOrderError(rbiOrderId);
      }
    } else {
      // non payment required means order needs to be price successful
      if (status === RbiOrderStatus.PRICE_ERROR) {
        throw new OrderPriceError(rbiOrderId);
      } else if (status !== RbiOrderStatus.PRICE_SUCCESSFUL) {
        throw new OrderStatusMismatchError(rbiOrderId, RbiOrderStatus.PRICE_SUCCESSFUL);
      }
    }

For the winrest integration, the code messages the POS vendor configured in the rbi/{env}/{brand}/partners-api secret inRBI account secrets DynamoDB table.

Sodexo/Cheque Gourmet example

One recent change that appears to be very similar to what will be necessary for our case was the inclusion of sodexo and cheque gourmet as payment methods, that were implemented in

Winrest integration

To configure the integration with Winrest team, we’ll need to send them the exact string of the new payment method so they can configure it on their platform (Aligned with Paulo Silva). The drawback of using payment type as CASH and a new payment method brand (eg. CARD_AT_HOME) is that the integration still works, but in Winrest reports these payments will be included as cash.

Frontend

Assumptions and possibilities

For this new feature, some places in the WL App can be impacted depending on the UI/UX that we design for the proposals:

• Method payment selection

• Order confirmation

• Recent orders

Other possible places:

• Email receipt

Places where we’ll have the new payment method

Business problems to be solved

---

Proposed solution

Configure “card at home” using the CASH payment method and CARD_AT_HOME payment method brand as an option. This was the solution used to implement Sodexo and Cheque Gourmet vouchers, which allowed us to take advantage of the groundwork laid by it: /wiki/spaces/IN/pages/3932717313

Pros and cons

Pros

• Require small changes since the structure is very similar to Sodexo and Cheque Gourmet vouchers

  • Reuse of components and structures that already exists on the code

• Avoids the complexity of creating a new payment method from scratch, which impact many repositories and integrations

Cons

• Since Winrest processes payment using paymentMethod field, it can’t differentiate between cash, voucher, or “card at home” payments

Out of scope

• Saving the Card brand used for “Card at home” payments for future reports. This information is not saved today.

Design analysis

Whitelabel changes

PS: click on the images below to open (I don’t want to flood the document with big images).

Account payment methods

Method payment selection

Order confirmation

As the flow will be similar to the payment with cash option we believe that we'll not need to change many details on this screen and we'll just change the information about the payment method.

Tracking modal

Email receipt

I think that we'll need to return the payment method description for this new method. A possibility about this email template is that it is controlled/used in Amazon SNS. I'll validate this with Caes, Guilherme.

Proposed solution

Configure card at home using CASH payment method and

Technical discovery

Architecture AS-IS

Image Added

Winrest integration

To configure the integration with Winrest team, we’ll need to send them the exact string of the new payment method so they can configure it on their platform (Aligned with Paulo Silva). The drawback of using payment type as CASH and a new payment method brand (eg. CARD_AT_HOME payment method brand. This was the solution used to implement Sodexo and Cheque Gourmet vouchers, which allow us to take advantage of the groundwork layed by it:

Pros and cons:

Pros

• Requirers small changes since the structure is very similar to Sodexo and Cheque Gourmet vouchers.

Cons

• Since Winrest processes payment using paymentMethod field, it can’t differenciate between cash, voucher, or card at home payments.

) is that the integration still works, but in Winrest reports these payments will be included as cash.

Necessary changes

intl-packages

• Update Order types with new PaymentMethodBrand: https://github.com/rbilabs/intl-packages/blob/master/packages/orders/src/types/cart.ts#L862

• Update SDKs

intl-whitelabel-graphql

• update graphql PaymentMethodBrand GraphQL definition: https://github.com/rbilabs/intl-whitelabel-graphql/blob/70138056e799d938a3a6bb39b502aba76c0a2c46/src/functions/graphql/schemas/payments.gql#L28

• Save CASH_AT_HOME payments status as PAYMENT_REQUIRED

          ...
          const isSodexoOrChequeGourmet = !!payment?.paymentMethodBrand;

          // we set the status to PAYMENT_REQUIRED for cash
          if ((isCashPayment && cashPaymentEnabled) || isSodexoOrChequeGourmet) {
            const updatedCart = {
              ...updatedOrder.cart,
              payment: {
                cardType,
                paymentMethodBrand: payment?.paymentMethodBrand || undefined,
              },
            } as ICart;
            ...