✅ Proposed Solution

Frontend - MB WAY

After selecting the MBWay payment method, we will implement two new screens for the user to enhance their payment experience.

Create a mb way payment method

• This screen will provide the user with clear instructions on how to complete their payment using MBWay.

https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=40562-25172&t=OZuRKZNKCPJTSM5t-0

• It will include:

  • A brief overview of the MBWay payment process.

  • A field for the user to enter their phone number. This phone number is crucial, as it will be used by Paycomet to create the payment request in the user's MBWay account.

  • A "Confirm" button for the user to proceed after entering their phone number.

  • A regex to validate phone number input (only for ES and PT)

    • The user can fill with only phone number ( PT Example )

      • User Input: 98333 0099 (no spaces)

      • Input Mask: 98333-0099

      • Final Result: 351983330099

    • The user can fill with ISO Country Code and phone number ( PT Example )

      • User Input: 351 98333 0099 (no spaces)

      • Input Mask: +351 98333-0099

      • Example: 351983330099

Create a component to be used in payment page and recent orders

• This screen will notify the user that their payment request has been successfully created.

• It will include:

  • A message indicating that the payment request is pending and that the user should complete their payment via the MBWay app.

  • Information on the payment details such as the amount to be paid.

  • A countdown timer displaying the remaining time for the user to complete the payment.

  • Instructions on what to do if they need to cancel the order.

• Additionally, an order polling process will be implemented on this screen to continuously check the payment status.

  • The polling will detect when the payment status changes to (PAYMENT_SUCESSFUL, INSERT_SUCESSFUL and UPDATE_SUCESSFUL).

  • Upon successful payment, the user will be automatically redirected to the /order-confirmation screen, where they will receive confirmation of their order and further instructions.

Frontend - Payment Tracking

After the user makes a payment request and closes the app, we need to ensure the user knows what happened to their order. This involves two developments: one is a new component to handle pending payments, and the other is a page to which the user will be redirected when attempting to view their pending payments.

Create a reusable component to search for pending payment

On the main screen of the Whitelabel app, we will add a component similar to the order tracking feature. However, this component will specifically monitor pending payments that are still within the payment deadline.

The primary goal of this component is to provide clarity to users who may close the Whitelabel app during the payment process. It ensures that users do not mistakenly believe their payment has been canceled. Even if the user closes the app, we do not have the capability to cancel their payment request in the MBWay application.

This component will include a button labeled SHOW which will redirect the user to a new MBWay page, that will be detailed in the next topic.

Create Reusable Waiting Payment Page for order pending

This page reuses the same component as the mb payment details ensuring that users are familiar with the layout and can easily find the information they need. The primary objective of this page is to offer users comprehensive details about their pending MBWay payments, in scenarios where they might have closed the whitelabel app during the payment process. It helps clarify the payment status and guides users on completing their transactions successfully.

Backend

Create Payment Request

To create a payment request for MBWay, it is necessary to add a new endpoint called InitiatePayment that handles the initialization of a new payment. Unlike the GenerateCheckoutLink, which is used for other payment methods, in the case of MBWay, we will not generate a link. Instead, we will request Paycomet to create a payment request in the customer's MBWay account.

title Create Payment Request

participant Frontend
participant Graphql/Fulfillment
participant DB
participant Payment Service
participant PSP Service
participant Paycomet External

Frontend->Graphql/Fulfillment: Initiate Payment
Graphql/Fulfillment->Payment Service: Initiate Payment
Payment Service->PSP Service:Initiate Payment
PSP Service->Paycomet External:Payments Endpoint
PSP Service<-Paycomet External:Result
Payment Service<-PSP Service:Result
Graphql/Fulfillment<-Payment Service:Result
Frontend<-Graphql/Fulfillment:Result
Frontend->Frontend:Order Polling
Frontend<-DB:Order Result

For this communication, it is necessary to transmit two important pieces of information to the Paycomet service: the amount and the cellphone. The cellphone will be used by Paycomet to create a request in the user's MBWay account. Once the data reaches the Paycomet service, we will create a payload as mentioned below for the /payments endpoint of Paycomet.

With this, Paycomet will return whether the request was created or not, allowing us to handle this data at the beginning of the request in the frontend, ensuring direct communication of the responses. If the endpoint returns success, it means that the user received a payment request. Otherwise, the user did not receive any request, and we should inform the user to try again, either because they entered an unregistered number or due to an issue on Paycomet's side.

"payment": {
    "terminal": XXXXX,
    "order": "000012345", // from request
    "amount": "202", // from request
    "currency": "EUR",
    "methodId": "38",
    "secure": 1,
    "urlOk": "https://www.paycomet.com", // psp-outcome-endpoint
    "urlKo": "https://www.paycomet.com", // psp-outcome-endpoint
    "merchantData": {
        "customer": {
            "name": "John", // from request
            "surname": "Doe", // from request
            "email": "john@doe.com", // from request
            "mobilePhone": {
                "cc": "351", // from request
                "subscriber": "931301715" // from request
            }
        },
        "billing": {
            "billAddrCountry": 620 // Portugual ISO 
        }
    }
}

Retrieve Payment Status

The retrieval of payment status data is performed through an order polling process that waits for the order to reach the status: PAYMENT_SUCCESSFUL. To facilitate this process, we utilize a webhook in the Paycomet service, which is triggered whenever the payment status is updated in the Paycomet payment service provider.

When the Paycomet service receives this information about the status change, it will trigger the payment services to notify that there has been a change. This will, in turn, trigger all other services so that the order is updated in the database and this information is reflected on the frontend.

Development

This first stage involves adding the main foundation for the new payment method. Since this task is repeated for all new payment methods, I will only provide the reference for each stage. This should be the first part of the frontend development; without it, it will not be possible to continue with the development of the subsequent screens.

New payment method support

Add new payment method icon

ref: https://github.com/rbilabs/ctg-components-library/pull/399

import { SVGIconComponent } from '../types';

export const endered: SVGIconComponent = ({ title = '', ...props }) => (
//svg code
);

export * from './mbway';

mbway: 'mbway',

mbway: string;

Create a new feature flag

https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4362960979/Technical+refinement+-+Front+end#Task-1%3A-Create-a-new-feature-flag

ref: IBFEC-1758 - Getting issue details... STATUS

time: 1h

Add the new payment method in the payment state and structure

https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4362960979/Technical+refinement+-+Front+end#Task-2%3A-Add-the-new-payment-method-in-the-payment-state-and-structure

ref: IBFEC-1761 - Getting issue details... STATUS

time: 8h

Add the new method in payment-method structure and payment list

https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4362960979/Technical+refinement+-+Front+end#Task-3%3A-Add-the-new-method-in-payment-method-structure

https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4362960979/Technical+refinement+-+Front+end#Task-4%3A-Create-and-add-a-new-method-in-payment-method-option-structure

https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4362960979/Technical+refinement+-+Front+end#Task-5%3A-Adjust--account-payment-method-lists-to-deal-with-the-new-method

ref: IBFEC-1760 - Getting issue details... STATUS

time: 2d

Adjust the receipt email to show the correct message for the new payment method

https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4449861673/Technical+refinement+-+Frontend#Task-6%3A-Adjust-the-receipt-email-to-show-the-correct-message-for-the-new-payment-method

ref: IBFEC-1765 - Getting issue details... STATUS

time: 2h

Setup MBWay Payment

This is the second stage of the development tasks in the frontend. This phase involves the development of MBWay, where the screens and payment handling will be developed.

Create a mb way payment method

This is the first payment screen via MBWay. After selecting this payment method from the dropdown, the screen with the phone number input field should appear. This involves both the development of the screen and the validation and masking of the input.

export interface IPaycometMBWayFormProps {
  onResult: (outcome: OutcomeResult) => void;
  rbiOrderId: string;
}

export const PaycometMBWayForm = ({ rbiOrderId, onResult }:IPaycometMBWayFormProps) => {
  .....
  .....
  .....
  
  const handlePayment = () => {
    setIsLoading(true)
    handleInitiate();
  }
  
  return(
    {isWaitingPayment ? 
      <TimerForm/> :
      <CellphoneForm onClick={handlePayment}/>
    }
  )
}

Handle Fulfillment Initiate

This task focuses more on handling the information after the user enters the phone number and clicks "Continue." This stage involves communication with the "Initiate Payment" endpoint and returning the result. Additionally, this screen includes the invocation of the error modal.

handleInitiateMBWayPayment(() => {
  const result = initiatePayment({
    cellphone: input.cellphone,
    amount: order.amount,
    rbiOrderId: order.id,
  })
  
  if(response.graphqlErrors[0]){
    showModal(true);
    return
  }
  
  LocalStorage.setItem(
    StorageKeys.PENDING_PAYMENTS,
    JSON.stringify({orderId: order.id})
  );  
  
  isProcessingMbWayPayment(true);
  placeOrder(true); // it is necessary placeOrder to enable backend commit order
})

Handle Commit Order

This task covers the order commit, where we will add a new field called paymentRequestCreatedAt, which will be responsible for recording when the payment request was generated. This field will be used in the future on the "Waiting for Payment" screen. It is important to remember that saveCommitOnly must be enabled for the order commit in the backend to be activated.

commitInput = {
  ...commitInput,
  payment: {
    paymentRequestCreatedAt: 1627383253213, //timestamp
    ...commitInput.paymemt
  }
}

Payment Pending Tracking

Tracking Page

This task involves handling the information for the "Waiting for Payment" screen when the payment request is made. Therefore, a generic screen should be developed that can be used by other future payment methods. Additionally, this screen should be displayed when the user closes the app and returns to the homepage, as long as there is still an active payment to be completed.

export const routes = {
  pendingPage: 'pendingPage'
}

const MBWayPaymentPage: LazyRoute = lazyWithFallback(() => import('pages/mbway'));

return(
  ...
      <Route
        noIndex
        path={`${routes.pendingPage}/:orderId`}
        element={<pendingPage />}
      />
  ...
)

const pendingPage = () => {
  const { orderId } = useParams();
  const MBWayPendingPayment = LocalStorage.getItem(StorageKeys.PENDING_PAYMENT);
  
  let data;
  if(MBWayPendingPayment && MBWayPendingPayment.id === orderId){
    data = MBWayPendingPayment;
  } else {
    try{
      const orders = GetUserOrders(); 
      // map the order list to show only the latest information needed
      data = orders[0];
    }
  }
  
  return (
    <MBWayComponent data={data} />
  )
}

Backend

Packages

export declare enum PaymentMethodType {
    ...
    MBWay = 'MBWay'
}

export declare enum RBIPaymentType {
    ...
    MBWay = 'MBWay'
}

Commit Order Graphql/Fulfillment

export enum CartPaymentType {
  ...
  MBWay = 'MBWay',
}

export interface IPaycometPaymentSaleEvent extends IBaseSale {
  ...
  paymentRequestCreatedAt?: number;
}

paycometSale = {
  ...
  paymentRequestCreatedAt: payment.paymentRequestCreatedAt,
};

private mapPaymentMethod(
    params: IPaycometPaymentSaleEvent,
  ): {
    paymentMethodType: string;
    paymentMethod: string;
  } {
    ...

    return {
      paymentMethodType: params.paymentRequestCreatedAt &&
                           params.paymentMethodType ? 'MBWay' : 'scheme',
      paymentMethod: JSON.stringify({
        type: 'scheme',
        subtype: 'onetime',
      }),
    };
  }

//PaymentType = MBWay;
//PaymentMethodBrand = null;

CommitOrderInput
  Input.payment.mbway = {
    cellphone: string
    createdAt: number;
  }

Create a new request to Graphql/Fulfillment to handle MB Way on Initiate Endpoint

Implementation example: https://github.com/rbilabs/intl-whitelabel-graphql/pull/1150/files

input PaycometCaptureContextInput {
  amount: number!
  rbiOrderId: String!
  cellphone: number
  method: string!
}

input InitiatePaymentInput {
  storeId: String!
  paymentMethodType: String!
  cybersourcePaSetup: CybersourcePaSetupInput
  cybersourceCaptureContext: CybersourceCaptureContextInput
  paycometCaptureContext: PaycometCaptureContextInput
}

Create a new endpoint in Paycomet PSP Service

export enum TypePayment {
  ...
  MBWay = 'MBWay'
}

export abstract class PspInitiateRequestDto {
  @AmountApiProperty()
  @IsOptional()
  @IsNumber()
  public amount: number;
  
  @RbiOrderIdApiProperty()
  @IsString()
  @IsNotEmpty()
  public rbiOrderId!: string;
  
  @IsOptional()
  @IsNumber()
  public cellphone: number;
  
  @IsString()
  @IsNotEmpty()
  public method!: string;
}

public initiatePayment(
    @Headers('region') region: string,
    @Body() pspInitiateRequestDto: PspInitiateRequestDto,
  ): Promise<ApiResult<unknown>> {
    if(pspInitiateRequestDto.method === TypePayment.MBWAY){
      return initiatePaymentMBWay(region, pspInitiateRequestDto);
    }
    return throw ApiErrorHttpException.createConflict(
        new ApiError(501, 'Initiate Payment request failed', 'initiatePayment'),
    );
  }

public async initiatePaymentMBWay(
    region: string,
    request: InitiateRequestDto,
  ): Promise<InitiateResult> {
    try{
      const result = this.createPaymentMBWayRequest(request);
      // Add log about payment initiation attempt
      if(result.errorCode === TransactionStatus.SUCCESSFUL){
        return this.handleSuccesful(region, request, result);
      }
      return this.handleFailure(region, request, result);
    } catch(error){
      return this.handleFailure(region, request, error);
    }
}

Update the order to include the time left to finish the MB Way Payment

Admin App

const paymentMethodType = order?.cart?.payment?.type;

if (paymentMethodType === 'MBWay') {
      return formatMessage({ id: paymentMethodBrandTranslationMap(paymentMethodType) });
    }
    
if (paymentMethodBrand) {
      return formatMessage({ id: paymentMethodBrandTranslationMap(paymentMethodBrand) });
    }

DOP

export const paymentMethodTranslation: Record<string, keyof LocalizedDictionary> = {
  MBWAY: `${pathPaymentTranslations}.mbway`,
};

Expeditor Tablet

export enum PaymentMethod {
  ...,
  MBWAY = "MBWAY",
}

Potential Challenges

The most complex part was understanding the payment flow via endpoint and how we would achieve the result of creating the initiate payment. Since this solution does not involve an iframe, it will slightly change the way this payment method is developed and how it handles edge cases.

Another problem was dealing with the fact that we cannot cancel an MB Way payment, only the user has the power to do that. This caused some user experience difficulties in the whitelabel solution, where the user, even outside the payment page, can still complete the payment if they are within the allowed time.

🎛️ Configuration

LaunchDarkly

🧑‍🚒 QA Plan

Test Scenario	Steps	Screenshots
SCENARIO 1: The user makes a payment	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user accepts the payment in the MB Way app. The user returns to the whitelabel app. The user is redirected to the order confirmation page.	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=40558-24217&t=OZuRKZNKCPJTSM5t-0
SCENARIO 2: The user makes a payment and closes the whitelabel app ( Delivery )	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user closes the whitelabel app. The user accepts the payment in the MB Way app. The user returns to the whitelabel app. A tracking modal appears for the user to track the order.	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=42110-4286&t=OZuRKZNKCPJTSM5t-0
SCENARIO 3: The user makes a payment and closes the whitelabel app ( Pickup )	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user closes the whitelabel app. The user accepts the payment in the MB Way app. The user returns to the whitelabel app.	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=42110-4287&t=OZuRKZNKCPJTSM5t-0
SCENARIO 4: The user makes a payment, closes the whitelabel app, doesn't pay in the MB Way app, opens the whitelabel app, the payment is still valid and user is redirect to waiting payment page.	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user closes the whitelabel app. The user returns to the whitelabel app. The user is redirect to waiting payment page	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=42037-29391&t=G7781FC1ZSRNblsB-0
SCENARIO 6: The user enters an incorrect phone number	The user selects MB Way from the payment list. The user fills in the phone number field with an incorrect number. An error modal appears.	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=42037-29246&t=OZuRKZNKCPJTSM5t-0
SCENARIO 7: The user makes a payment and the time limit expires	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The timer finishes, and an error modal appears.	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=42037-29247&t=OZuRKZNKCPJTSM5t-0
SCENARIO 8: The user makes a payment and cancels in the MB Way app	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user cancels the payment in the MB Way app. An error modal appears.	https://www.figma.com/design/RtD0UFtwuwXx14lbLCAPlr/branch/OWwFfjThLHwiZkB2dvJKgv/9.-Checkout?node-id=42037-29247&t=OZuRKZNKCPJTSM5t-0
SCENARIO 9: Guest receives the email after placing the order	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user accepts the payment in the MB Way app. The user returns to the white-label app. The user is redirected to the order confirmation page. The user receives an email informing them that the order has been placed.
SCENARIO 10: The support tool user can see the order receipt	The order is placed. The support user can see the order in the support tool. The support user selects the order. The support user can see the order details. The support user can see that the order is paid via the MB Way app.
SCENARIO 11: The DOP user can see the order receipt	The order is placed. The user can see the order in the DOP. The user selects the order. The user can see the order details. The user can see that the order is paid via the MB Way app.
SCENARIO 12: The DMP user can see the order receipt	The order is placed. The user can see the order in the DMP. The user selects the order. The user can see the order details. The user can see that the order is paid via the MB Way app.
SCENARIO 13: Make a refund in the support tool	The order is placed. The support user can see the order in the support tool. The support user selects the order. The support user can see the order details. The support user can make a refund.
SCENARIO 14: Make a partial refund in the support tool	The order is placed. The support user can see the order in the support tool. The support user selects the order. The support user can see the order details. The support user can make a partial refund.
SCENARIO 15: Make a refund in DMP	The order is placed. The user can see the order in the DMP. The user selects the order. The user can see the order details. The user can make a refund.
SCENARIO 16: Autorefund	The order is placed. The order is cancelled for any reason. The autorefund is triggered by the system. The support user can see the order in the support tool. The order is refunded
SCENARIO 17: Phone input error	The user selects MB Way from the payment list. The user fills in the phone number field a wrong value. The user cannot click continue button.
SCENARIO 18: Payment Refused	The user selects MB Way from the payment list. The user fills in the phone number field. The user is redirected to the "Waiting for Payment" screen. The user refuse the payment in the MB Way app. The user see a payment refused modal The user is redirect to cart page
SCENARIO 19: Payment Refused by time expired	The user selects MB Way from the payment list. The user fills in the phone number field a wrong value. The user is redirected to the "Waiting for Payment" screen. The user waits for time limit to end The user see a payment refused modal The user is redirect to cart page
SCENARIO 20: Insert a phone number without iso code country	The user selects MB Way from the payment list. The user fills in the phone number field with only phonenumber (e.g., 983334571). The user is redirect to waiting payment page.
SCENARIO 21: Insert a phone number with iso code country	The user selects MB Way from the payment list. The user fills in the phone number field with only phonenumber (e.g., 351 983334571). The user is redirect to waiting payment page.

How to test

Unfortunately, Paycomet does not provide a way to perform tests in a development environment. Therefore, it will not be possible to conduct an end-to-end test of this new feature. What will be described below is a way to simulate a response from Paycomet when the payment is completed in MB Way App.

Make a Payment

The first step is to follow the happy path flow of the payment method, that is, choose an order, go to the checkout screen, fill in the necessary information, select the MB Way payment method, enter the phone number: "351 931301715" and click on pay. After that, you will be redirected to the MB Way waiting screen, and now you need to proceed to the next step.

Make a request to notification in paycomet-service

Below you will find an example of how to create the notification request to the endpoint. After creating this request, make a call to the Paycomet service at the notification endpoint. If the request is correctly created, the order status will be updated to success, and the Whitelabel app will redirect the user to the order confirmation screen.

{
  "AccountCode": "", // AccountCode (can be found in paycomet logs) IMPORTANT
  "Amount": 2146, // Amount (can be found in paycomet logs) IMPORTANT
  "AmountEur": 21.46,
  "AuthCode": 341348, // Amount (can be found in paycomet logs) IMPORTANT
  "BankDateTime": 20240814195535, // !BankDateTime (can be found in paycomet logs) IMPORTANT
  "BicCode": "BSABESBBXXX",
  "CardBrand": "VISA",
  "cardCategory": "CONSUMER",
  "CardCountry": "ES",
  "cardType": "CREDIT",
  "ClearanceDateTime": 20240814195535,
  "Currency": "EUR", // Currency (can be found in paycomet logs) IMPORTANT
  "DCC_Amount": "",
  "DCC_Currency": "",
  "DCC_CurrencyName": "",
  "DCC_EcbPercentage": "",
  "DCC_ExchangeRate": "",
  "DCC_Markup": "",
  "ErrorDescription": "", // ErrorDescription (can be found in paycomet logs) IMPORTANT
  "ErrorID": 0, // ErrorID (can be found in paycomet logs) IMPORTANT
  "ExtendedSignature": "", // ExtendedSignature (can be found in paycomet logs)
  "IdUser": 00000000, // IdUser (can be found in paycomet logs)
  "Language": "es",
  "MethodId": 1,
  "MethodName": "", // MethodName (can be found in paycomet logs)
  "NotificationHash": "", // Paycomet Service has the validatePaymentHash
                          // function to help you create the hash IMPORTANT
  "Order": "", //rbiOrderId (can be found in paycomet logs) IMPORTANT
  "paycometId": 00000000, // PaycometId (can be found in paycomet logs)
  "Response": "OK",
  "SecurePayment": 1,
  "sepaCard": 1,
  "Signature": "", // Signature (can be found in paycomet logs)
  "TokenUser": "", // TokenUser (can be found in paycomet logs)
  "TpvID": 0000, // TpvID (can be found in paycomet logs) IMPORTANT
  "TransactionName": "Autorización",
  "TransactionType": 1 // TransactionType (can be found in paycomet logs) IMPORTANT
}