Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 38 Next »

Table of Contents


Business problem

Payment at home with credit card represents 41% of the payments in Portugal today. With that in mind, this is a crucial feature for our customers to guarantee the best experience. The idea is to deliver a new method of payment (that we'll call here "Card at home"). To see more details: Feature - Payment with card at home

OUT OF SCOPE: Saving card networks (ex: Visa, Mastercard) used for “Card at home” payments for future reports. This information is not saved today.

Design analysis

Whitelabel proposed 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.

Technical discovery

Architecture AS-IS

Winrest integration

The "Card at home" feature will affect the payload sent by partners-api to Winrest. 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.

Tech solutions - comparison

Payment method brand

Payment method

PROS

  • Small changes in seven repositories: packages, fulfillment, payments, partners, WL graphql and WL app

  • Avoid the complexity of creating a new payment method

  • Avoid impacting WinRest roadmap

CONS

  • Impacts Winrest integration. They will have to change their code to take paymentMethodBrand into consideration

  • The scope of the changes necessary to include a new payment method is still unclear. This will affect the business logic of many services

  • Requires implementing the business logic of a new payment method from the start, instead of using the CASH workflow (high complexity in payment workflows)

  • Bigger changes increase the likelihood of conflicts between this feature and the ongoing refactoring of payment workflow

Tech solution 1 - Payment method brand

Using the CASH payment method, add CARD_AT_HOME payment method brand as an option. This solution was used also to implement Sodexo and Cheque Gourmet vouchers, which allowed us to take advantage of the groundwork laid by it: /wiki/spaces/IN/pages/3932717313. The exact changes needed are listed in Necessary changes section.

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. The same behavior happens today to Sodexo and Cheque Gourmet Vouchers, however, without this information, the driver won’t know if they have to take the card machine.

Necessary changes

intl-packages

intl-fulfillment-service

  • Update method brand enum and intl-packages versions

intl-payment-service

  • Update method brand enum and intl-packages versions

intl-partners

  • Update method brand enum and intl-packages versions

intl-whitelabel-graphql

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

intl-whitelabel-app

  • Update payment flow to include “Card at home” as an option. The impacted pages have been listed in Design Analysis section. Schroer, Gabriel (Deactivated) is working on the final design.

  • Possible main changes in

    • Components:

      • Payment

      • PaycometHostedPagePayment

      • PaymentMethod

      • PaymentMethodAddNewItemOption

      • PaymentMethodOption

      • PaymentMethodOptions

      • PaymentMethodFlatListWithButton

    • Hooks:

      • useOrderPayment

Tech solution 2 - Payment method

Create a new payment method. This is one of the core payload fields used in the payment workflow and the full extent of necessary changes is still unclear, but it will require implementing the business logic of “card at home” from zero instead of taking advantage of the existing CASH workflow.

Pros and cons

Pros

  • Avoid impacting WinRest roadmap

Cons

  • The scope of the changes necessary to include a new payment method is still unclear. This will affect the business logic of many services

  • Requires implementing the business logic of a new payment method from the start, instead of using the CASH workflow (high complexity in payment workflows)

  • Bigger changes increase the likelihood of conflicts between this feature and the ongoing refactoring of payment workflow

Necessary changes

The full scope of changes is still unclear.

  • No labels

0 Comments

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.