Document Status	in-progress
Document Owner(s)	@Capovilla, Evandro (Deactivated)
Reviewers	@Ferreira Gomes, Raphael (Deactivated) @Ruani, Andrea (Deactivated) @Augusto Romao, Vinicius (Deactivated) @Franca, Helio (Deactivated)

1 Potential Solutions
2 Proposed Solution
- 2.1 Send cardholder name field to paycomet
  - 2.1.1 One time
    - 2.1.1.1 Whitelabel App (Already done)
    - 2.1.1.2 GraphQL
    - 2.1.1.3 Fulfillment
    - 2.1.1.4 Payment Service (Already done)
    - 2.1.1.5 Paycomet Service
  - 2.1.2 Pre-auth
    - 2.1.2.1 Whitelabel App (Already done)
    - 2.1.2.2 GraphQL (Already done)
    - 2.1.2.3 Paycomet Service
  - 2.1.3 Vaulted
  - 2.1.4 Vaulted - Pre-auth
- 2.2 Update phoneNumber field to use user accounts or delivery data
  - 2.2.1 Whitelabel App
3 Configuration
4 QA Plan
5 Call-outs

Potential Solutions

Assumptions

We are sending the name as the first string until de empty string.
We are sending the surname as the rest of the name after the first empty string
We are using the same feature flag to send user details to send first name and last name data
Mandatory fields are still being sent (email and/or cell phone)
The workPhone and homePhone fields are not mandatory due to the rule above
The IpAddress field has already been sent - No changes necessary
The cardholderName field only requires updates in BE

#1 - Send cardholder name field to paycomet

The idea is to send the cardholder name in the merchantData in the make payment request to paycomet.

The user will fill the cardholder name field that already exists

We guarantee that the name is related to the credit card

#2 - Send profile user’s name to paycomet

The idea is to get the profile user’s name to send the information to paycomet.

We reuse the profile user’s name

We can’t guarantee that the name is related to the credit card

Proposed Solution

Send cardholder name field to paycomet

One time

Payment made with a new credit card

title Make purchase/No pre-auth

FE->Graphql:CommitOrder
Graphql->Payment-Service:MakePayment
Payment-Service->Paycomet-Service:MakePayment
Paycomet-Service->Paycomet: executePurchase
Paycomet-Service<-Paycomet: result
Payment-Service<-Paycomet-Service:result
Graphql<-Payment-Service:result
FE<-Graphql:result

Pre-auth removal refence: https://rbictg.atlassian.net/wiki/spaces/TRX/pages/4312367174/Paycomet+-+Pre-auth+removal#Integration-steps-TO-BE-(Delivery)

Whitelabel App (Already done)

The frontend will be responsible for displaying and retrieving the cardholderName field and sending this information to paycomet. Nowadays this information is already sent via Paycomet forms, but they also need it to be sent via the merchantData field.

This is an example of cardholder data recovery already developed.

if (paymentMethod.source === CartPaymentCardType.CREDIT) {
        ...,
        const cardPayload = {
          ...,
          nameOnCard: paymentMethod.cardholderName || '',
          card: {
            ...,
          },
          ...,
        };
        
        handlePaycometSuccess({ ...cardPayload, paymentMethodBrand });
      }

commitInput = {
            creditType: payCometValues.cardType,
            order,
            payment: {
              fullName: payCometValues.nameOnCard || '',
              ...,
            },
            ...,
          };

GraphQL

Today we get the username from user accounts instead of getting the credit card name, which is already sent by whitelabel.

Before

paycometSale = {
  ...,
  fullName: paymentUserDetails.name!,
  ...,
};

After

paycometSale = {
  ...,
  fullName: payment?.fullName || paymentUserDetails.name!,
  ...,
};

Fulfillment

The same that we did for graphql we need to replicate in the fulfillment

Before

paycometSale = {
  ...,
  fullName: paymentUserDetails.name!,
  ...,
};

After

paycometSale = {
  ...,
  fullName: payment?.fullName || paymentUserDetails.name!,
  ...,
};

This code has already been implemented

private mapPaymentMethod(
    params: IPaycometPaymentSaleEvent,
  ): {
    paymentMethodType: string;
    paymentMethod: string;
  } {
    const isVaultedPayment = !params.storePaymentMethod && params.storedPaymentMethodId;

    if (isVaultedPayment) {
      return {
        paymentMethodType: params.paymentType,
        paymentMethod: JSON.stringify({
          ...,
          cardholderName: params?.fullName,
          ...,
        }),
      };
    }

    return {
      paymentMethodType: params.paymentType,
      paymentMethod: JSON.stringify({
        ...,
        cardholderName: params?.fullName,
        ...,
      }),
    };
  }

Payment Service (Already done)

const pspRequestDto: PaymentBaseRequestDto = {
  ...,
  paymentMethod,
  ...,
};
    
...
const resp = await this.pspClient.makePayment(region, psp, pspRequestDto);
...

Paycomet Service

export class VaultedSchemeDto extends PaymentMethodBase {
  @ApiProperty({
    required: false,
    example: 'John Smith',
    description: 'Cardholder name',
  })
  @IsString()
  @IsOptional()
  public cardholderName?: string;
}

interface ICustomerData {
  mobilePhone?: IMobilePhone;
  email?: string;
  name?: string;
  surname?: string;
}

The idea here is to update the buildUserDetails function to handle first and last name, since the responsibility of this function is to generate the customer field.

Create two function parseName and parseSurname, to handle the cardholderName to send to paycomet.

Update the buildUserDetails function and tests.

public buildUserDetails = (
    region: string,
    cellphone?: string,
    email?: string,
    paymentMethod?: PaymentMethod
  ): TCustomer | undefined => {
    if (!cellphone && !email && !paymentMethod.cardholderName) {
      return undefined;
    }
    return {
      mobilePhone: cellphone ? this.parsePhoneNumber(cellphone, region) : undefined,
      email: email || undefined,
      name: parseName(paymentMethod.cardholderName)
      surname: parseSurname(paymentMethod.cardholderName)
    };
  };

public async handlePurchase(...){
  ...
  const customer = this.paycometHelper.buildUserDetails(region, cellphone, email, request);
  ...
}

Pre-auth

Payment made with a new credit card and pre-auth is enabled

title Pre-auth

FE->Graphql:CreatePreAuth
Graphql->Paycomet-Service:CreatePreAuth
Paycomet-Service->Paycomet: createPreauthorization
Paycomet-Service<-Paycomet: result
Graphql<-Paycomet-Service:result
FE<-Graphql:result

Pre-auth reference: https://rbictg.atlassian.net/wiki/spaces/TRX/pages/3929702586

Whitelabel App (Already done)

generateCreatePreAuthorization({
        variables: {
          input: {
            ...,
            cardHolderName: paymentValues.nameOnCard,
            ...,
          },
        },
      });

GraphQL (Already done)

public async createPreAuthorizationPaycomet({...}){
  const paycometPreauth =
    await this.paymentsClient.paycometClient.request<ICreatePreAuthorizationResponse>((apis) =>
      apis.paymentsApi.createPreAuthorization({
        iCreatePreAuthorizationRequest: {
          ...,
          cardHolderName,
          ...,
        },
        region: regionCountry,
      }),
    );
}

Paycomet Service

public async processPreAuth(...){
  ...
  const customer = this.paycometHelper.buildUserDetails(region, cellphone, email, request);
  ...
}

Vaulted

No update required

Vaulted - Pre-auth

No update required

Update phoneNumber field to use user accounts or delivery data

The idea here is to mainly use the phoneNumber from the cart page ( delivery mode ) and if it doesn't exist, we use the phoneNumber from the user data ( restaurant mode ). If neither of these fields exist, we are sending that data as empty.

Whitelabel App

One-time:

const {
  ...,
  orderPhoneNumber,
} = useOrderContext();

const placeOrder = useCallback(async () => {
  ...
  
  const userPaymentDetails = enablePaycometPaymentUserDetails
    ? {
        phoneNumber: orderPhoneNumber ?? auth.user?.details?.phoneNumber,
        email: auth.user?.details?.email,
      }
    : undefined;
    
  ...
  
}

Vaulted:

const {
  ...,
  orderPhoneNumber,
} = useOrderContext();

const processOrderWithAccount = useCallback(async () => {
  ...
  
  const userPaymentDetails = enablePaycometPaymentUserDetails
    ? {
        phoneNumber: orderPhoneNumber ?? user?.details.phoneNumber,
        email: user?.details?.email,
      }
    : undefined;
    
  ...
  
}

const { setRepriceOrderAfterNavigate, orderPhoneNumber } = useOrderContext();

...

if (rbiOrder?.rbiOrderId && accountIdentifier && vaultedPaymentConfirmed) {
  ...
  const userPaymentDetails = enablePaycometPaymentUserDetails
      ? {
          phoneNumber: orderPhoneNumber ?? auth.user?.details?.phoneNumber,
          email: auth.user?.details?.email,
        }
      : undefined;
  ...
}

const { setRepriceOrderAfterNavigate, orderPhoneNumber } = useOrderContext();

...

if (rbiOrder?.rbiOrderId && tpvToken) {
  ...
  const userPaymentDetails = enablePaycometPaymentUserDetails
      ? {
          phoneNumber: orderPhoneNumber ?? user?.details?.phoneNumber,
          email: user?.details?.email,
        }
      : undefined;
  ...
}

Configuration

Include here any configuration required (Sanity, LaunchDarkly flags, etc.) required to enable the solution.

Temporary Feature Flag

Temporary Feature Flag
enable-paycomet-payment-user-details

QA Plan

We can create the test cases following the doc below

[Test Cases] [Deprecated] Visa/Sibs - new mandatory fields

Call-outs

This functionality is made exclusively for the PSP Paycomet which is used in the Spanish and Portuguese environments.

The vaulted card will use the cardholderName saved in DynamoDB, we are not including an option to change this field.

Iberia Collaboration

[Solution] VISA/master/Sibs - Send Cardholder Name Field

Potential Solutions

Assumptions

#1 - Send cardholder name field to paycomet

#2 - Send profile user’s name to paycomet

Proposed Solution

Send cardholder name field to paycomet

One time

Whitelabel App (Already done)

GraphQL

Fulfillment

Payment Service (Already done)

Paycomet Service

Pre-auth

Whitelabel App (Already done)

GraphQL (Already done)

Paycomet Service

Vaulted

Vaulted - Pre-auth

Update phoneNumber field to use user accounts or delivery data

Whitelabel App

Configuration

QA Plan

Call-outs

Related content