Tech Discovery - Payment with card at home
- Caes, Guilherme
- Augusto Romao, Vinicius
- Ruani, Andrea
Table of Contents
- 1 Business problem
- 2 Design analysis
- 2.1 Whitelabel proposed changes
- 2.1.1 Account payment methods
- 2.1.2 Method payment selection
- 2.1.3 Order confirmation
- 2.1.4 Tracking modal
- 2.1.5 Email receipt
- 2.1 Whitelabel proposed changes
- 3 Technical discovery
- 4 Tech solutions - comparison
- 5 Tech solution 1 - Payment method brand approved by Winrest and Homeria
- 5.1 Pros and cons
- 5.2 Necessary changes
- 5.2.1 intl-packages
- 5.2.2 intl-fulfillment-service
- 5.2.3 intl-payment-service
- 5.2.4 intl-partners
- 5.2.5 intl-whitelabel-graphql
- 5.2.6 intl-whitelabel-app
- 6 Tech solution 2 - Payment method
- 6.1 Pros and cons
- 6.2 Necessary changes
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
The email templates will also have to be updated to display correct payment method. Today, they only take into consideration the value of payment method, and not payment method brand.
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. PAYMENT_ON_DELIVERY_CARD) 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 |
|
|
CONS |
|
|
Tech solution 1 - Payment method brand approved by Winrest and Homeria
Using the CASH payment method, add PAYMENT_ON_DELIVERY_CARD 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: https://rbictg.atlassian.net/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. This will require changes on Winrest side to also evaluate paymentMethodBrand, othewise the driver won’t know if they have to take the card machine.
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-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
update graphql PaymentMethodBrand GraphQL definition: https://github.com/rbilabs/intl-whitelabel-graphql/blob/70138056e799d938a3a6bb39b502aba76c0a2c46/src/functions/graphql/schemas/payments.gql#L28
Save PAYMENT_ON_DELIVERY_CARD 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;
...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
Front end tech refinement based on the Sodexo Voucher solution: Technical refinement - Front end
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, but a known change is updating the payment method enum in intl-packages, which will impact many repositories.