...
Subject | Description |
|---|---|
Whitelabel | localhost |
Test Deliverables
Test Plan (this document)
Test Cases
Bug Tasks
...
User Role | Description |
|---|---|
User | User will be placing successful orders on Whitelabel |
Developer user | User responsible for enabling : |
Key
CVV
Paycomet
Description
Modal Title
Modal Message
Modal CTA
Screen
Severity: 2 - NORMAL - Normal User Errors.
error.PAYMENT.2.001
130
Original operation not found. Could not refund
Operation not allowed for the credit card type
“Card type invalid”
“Your card is not enabled to allow this payment at the moment. Please, contact your bank or try another payment method.”
"Pay another way”
error.PAYMENT.2.002
Represents errors generated when a transaction is suspected of being fraudulent.
“Something went wrong"
“We had a problem processing this payment. Please try another payment method.”
"Pay another way”
error.PAYMENT.2.003
Represents errors generated by internal fraud detection mechanisms within the system.
“Something went wrong"
“We had a problem processing this payment with this payment method. Please contact your bank support or try another payment method"
"Pay another way”
error.PAYMENT.2.004
Represents errors that occur during the validation of transaction data, such as missing mandatory fields, incorrectly formatted data, and other validation failures.
“Validation error”
“The payment transaction was declined. Please check the card name, card number, CVV, expire date and try again.”
"Review Informations”
error.PAYMENT.2.100
Represents an error related to credit/debit card transactions.
“Card type invalid"
“Your card is not enabled to allow this payment at the moment. Please, contact your bank or try another payment method."
"Go back”
error.PAYMENT.2.100.001
111
CVC2 block incorrect
The payment transaction was rejected because the user informed an invalid card CVV.
“Validation error"
“The payment transaction was declined. Please check the card name, card number, CVV, expire date and try again.”
"Review Informations”
error.PAYMENT.2.101
Represents errors that arise during the payment processing phase, such as failures in communicating with the payment gateway, billing errors, and other issues that may occur while processing a payment.
“Something went wrong"
“We were unable to process this payment due to internal errors. Please try again later.”
"Go back”
error.PAYMENT.2.101.001
115
Card issuer could not validate card owner
The payment transaction was rejected because card issuer could not validate card owner's identity.
“Identity error"
“Sorry, we were unable to verify the cardholder's identity. Please authorize payment and try again.”
"Go back”
error.PAYMENT.2.101.002
1367
When the same card has several payments in "flight" at the time that one is finalized, the rest are denied with this code. This restriction is for security.
Represents an error when In-Flight offline payments are rejected.
An example of occurrence is when the same card has several payments in "flight" at the time and one is finalized, the rest might be denied.
“Something went wrong”
“Sorry, we are unable to process this payment. Please use another payment method.”
"Go back”
error.PAYMENT.2.102
Represents errors generated when a transaction is rejected as restricted by PSP or issuer.
“Something went wrong”
“Sorry, we are unable to process this payment. Please use another payment method."
"Go back”
error.PAYMENT.2.102.001
102
Operation not allowed for the credit card type
Operation is not allowed for this card type.
“Card type invalid”
“Your card is not enabled to allow this payment at the moment. Please, contact your bank or try another payment method.”
"Pay another way”
error.PAYMENT.2.102.002
1192
Country (customer IP address) not allowed
Represents an error when the user's IP address is not from an allowed country.
Ex.: Iberia payments only allowed from Spain and Portugal.
“Location Invalid"
“Sorry, we had a problem related to your location and this store. Please choose a nearest store and try again.”
"Choose another Store”
error.PAYMENT.2.102.003
1202
Number of failed attempts (last 30 minutes) from the same ip address exceeded
Represents an error when the number of failed attempts from the same user has been exceeded.
“Order limit exceeded"
“You have exceeded the number of attempts to place an order. Please try again later.”
"Go back”
Severity: 4 - ABNORMAL
error.PAYMENT.4.000
General, unspecified payment error.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.001
Represents errors related to security and authentication within the payment system.
Impact: All the payment transactions are failing.
Solution: Investigate security related settings, like secrets.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.002
Represents errors arising from system configuration issues.
Impact: All the payment transactions are failing.
Solution: Review the configuration for the specific service and PSP.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.003
Represents errors related to internal connection problems, such as failures in communication between microservices, internal network issues, or connectivity problems with the Payment Service Provider (PSP).
Solution: Investigate communication-related infrastructure issues
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.004
Represents errors associated with database operations within the system.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.005
Represents errors caused by failures in third-party connections with external services necessary for the transaction, such as banks, payment gateways, identity verification services, etc.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.006
Represents errors that occur due to external factors not directly related to the internal infrastructure of the payment system.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.007
Represents errors that occur at the service layer, such as internal service failures, configuration issues, or other problems that prevent the service from functioning as expected.
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
error.PAYMENT.4.008
Represents errors that occur during the internal processing of payment transactions.
Ex.: Payment not found for the given rbiOrderId
“Failed Payment”
“Something went wrong with this payment. Please try again later”
"Go back”
Traceability Matrix / Test Status
Scenario
Scenario Title
Pre- condition
How to execute(step-by-step)
1
[Mapped errors][Message Description] - Check if the custom description is displayed on the error modal
Mapped errors on Lokalise file according to the table below.
Back-end FF on LD enabled.
Access the WL and go to the payment screen.
Select credit card option.
On CVV type the <CVV> and confirm.
Check if the <Expected Message Description> is displayed on the error modal.
Scenario
Scenario Title
Pre- condition
How to execute(step-by-step)
2
[Non-Mapped errors][Message Description] - Check if the message description is displayed on the error modal
Mapped and non-mapped errors on Lokalise file according to the table below.
Back-end FF on LD enabled.
Access the WL and go to the payment screen.
Select credit card option.
On CVV type the <CVV> and confirm.
Check if the <Expected Message Description> is displayed on the error modal.
Scenario
Scenario Title
Pre- condition
How to execute(step-by-step)
3
[Mapped errors][Message Title] - Check if the message title is displayed on the error modal
Mapped errors on Lokalise file according to the table below.
Back-end FF on LD enabled.
Access the WL and go to the payment screen.
Select credit card option.
On CVV type the <CVV> and confirm.
Check if the <Expected Message Description> is displayed on the error modal.
Scenario
Scenario Title
Pre- condition
How to execute(step-by-step)
4
[Non-Mapped errors][Message Title] - Check if the message title is displayed on the error modal
Mapped and non-mapped errors on Lokalise file according to the table below.
Back-end FF on LD enabled.
Access the WL and go to the payment screen.
Select credit card option.
On CVV type the <CVV> and confirm.
Check if the <Expected Message Description> is displayed on the error modal.
Scenario
Scenario Title
Pre- condition
How to execute(step-by-step)
5
Analytics - Check if the new event and its attributes are being sent properly to mParticle/Amplitude according to the table below.
Mapped and non-mapped errors on Lokalise file according to the table below.
Back-end FF on LD enabled.
mParticle/Amplitude access
Access the WL and go to the payment screen.
Select credit card option.
On CVV type the <CVV> and confirm.
Build and run the local environment and set the mocks | |
Analytics user | User responsible for checking the events on mParticle/Amplitude. |
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.
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.