Page Comparison

...

This document details how the Detailed payment error messages Allow Payment methods by DOPfeature should be tested

...

Test Scope

...

Application	Description
Whitelabel	Whitelabel’s is where guests finish placing their orders, either it’s on mobile or the web.
Launch Darkly	Feature management platform that allows development teams to control and manage feature flags to release software updates safely and continuously.
LokaliseDOP	Translation management platform that helps teams streamline the localization process for their software and content.	Amplitude	Data AnalyticsA platform that allows the restaurant manager to edit the restaurant information such as the payment methods and cash limitation feature.
Sanity	CMS

Out of Scope

Application

Description

POS

Won’t be tested as this application won’t be changed by this feature's development

Kiosk

Call Center

...

User Role

Description

User

User will be placing successful orders on Whitelabel

Developer user

User responsible for:
Enabling the FF on the Launch Darkly (LD)

Build and run the local environment and set the mocks

Analytics DOP user

User responsible for checking the events on mParticle/Amplitudeenabling the payment methods.

Whitelabel

General configs and pre-conditions:

Feature flags Intl Platform (backend):

disable-paycomet-pre-auth: this FF needs to be enabled with these configs:

...

enable-rbi-error-2: this FF need to be enabled with these configs:

...

Test Part 1:

The test cases in part 1 should be performed in local environment because we are going to need the translations to be manipulated in each variation scenario and we also need to create mocks to simulate the errors coming from the backend. To do this:

1- Setup and run locally the Intl-whitelabel-graphql

Mock the backend error:

Find this file: intl-whitelabel-graphql/src/functions/graphql/providers/payments.ts

Add the code below:

const ccc = '2';

errorPayload.code = `PAYMENT.${ccc}`;
errorPayload.rbiErrorCode = ccc;

When the const ccc = ''; here you can set the backend error that you want to simulate. E.g. 2.001, 2.100.001 and etc.

Image Removed

2- Setup and run locally the Intl-whitelabel-frontend

Edit the file src/utils/errors/index.ts

replace the existing code from line 238 by the 261 by the code below:

Code Block

export const getRbiErrorTranslation = ({
  errorCode,
  errorTranslation,
  defaultTranslationId,
  formatMessage,
}: IRbiErrorTranslation) => {
  const parsedErrorCodes = errorCode ? extractRbiErrorCodes(errorCode) : [];

  const foundTranslation = parsedErrorCodes.find(code => {
    const key = errorTranslation ? `error.${code}.${errorTranslation}` : `error.${code}`;
    return formatMessageMock({ id: key as TLocalizationKey }) !== key;
  });

  const getFormattedMessage = (translation: string) =>
    formatMessageMock({
      id: errorTranslation
        ? (`error.${translation}.${errorTranslation}` as TLocalizationKey)
        : (`error.${translation}` as TLocalizationKey),
    });

  return foundTranslation
    ? getFormattedMessage(foundTranslation)
    : formatMessageMock({ id: defaultTranslationId as TLocalizationKey });
};

Go to line 21 and add the code below:

Code Block

export const formatMessageMock = ({ id }: { id: string }) => {
  const keys: Record<string, string> = {
    'error.payment.title': 'Uh oh!',
    'error.payment.default': 'Something went wrong, please try again.',
    'error.payment.cta': 'Go back',
    'error.payment.2.001.title': 'Card type invalid',
    'error.payment.2.001.cta': 'Pay another way',
    'error.payment.2.001': 'Your card is not enabled to allow this payment at the moment. Please, contact your bank or try another payment method.',
  };

  return keys[id] ?? id;
};

Now on this same part, add new variables and remove them according to the pre-conditions for each test case.
Build and run the front end and access the local host.
In order to simulate the error, you can use the specific credit card available by Paycomet on this document: https://docs.paycomet.com/en/recursos/testcards in the section Test Cards to force an error.
You can use any code available on this document: https://docs.paycomet.com/en/recursos/codigos-de-error on the CVV field, it will not make a difference, because you already created a mock on backend.

Test case scenario part 1:

Test Part 2:

The objective of test part 2 is really validate the codes already implemented on the backend and check if the messages on the frontend are correct according to the map.

You can validate using the test environments and just in case you want to local it is necessary to remove any mocks applied.

Use Paycomet’s instructions to simulate some of the mapped errors. In this case, we need to use the CVV field and enter the code informed by Paycomet. The codes are available in this document.

Versions Compared

Old Version 1

New Version Current

Key

Test Scope

Out of Scope

Whitelabel

General configs and pre-conditions:

Feature flags Intl Platform (backend):

Test Part 1:

Test Part 2:

Analytics

Test Part 3: