To simplify and accelerate integration with our payment flows, PPRO provides a mock authenticator in the Sandbox environment. This feature lets you simulate multiple authentication methods and reproduce a variety of authorization outcomes, enabling full end-to-end testing without real payments or dependency on a provider’s sandbox availability and functionality.

You can access the mock authenticator by setting the paymentMethod to MOCK. Different scenarios are simulated through combinations of the amount and paymentDescriptor fields. By supplying specific key combinations, you can reproduce a wide range of outcomes and test your integration under different conditions.

📘
For payment methods without a provider sandbox, or where the sandbox cannot support a full end-to-end flow, a preconfigured mock authenticator is used to replicate that payment method.

Authorization failures

It is possible to simulate specific authorization failures using the amount field. Failures always occur for amounts between 300000 (€3,000) and 400000 (€4,000), and specific errors can be triggered based on the subunit amount.

Authorization Error	Subunit Amount
failureCode: `GENERIC_DECLINE` failureMessage: `Payment Authorization Failed`	`01` Example: `300001`
failureCode: `INSUFFICIENT_FUNDS` failureMessage: `Payment Authorization Failed, insufficient funds`	`02` Example: `300002`

Payment transitions

It is possible to simulate different payment transitions, which are used to apply various states to a payment during processing.

paymentDescriptor Key	Description	Values
`requiresAuthentication`	Payment requires authentication. Triggers the `AUTHENTICATION_PENDING` status.	`true` `false`
`authenticationType`	Specify the available authentication methods. More info. Depends on `requiresAuthentication`	`REDIRECT` `SCAN_CODE` `MULTI_FACTOR` Default: `REDIRECT`.
`providerConfirmation`	Payment requires provider confirmation. Triggers the `AUTHORIZATION_ASYNC` status.	`true` `false`
`providerConfirmationDelay`	Specify the delay in seconds for provider confirmation. Depends on `providerConfirmation`	`nns` Default: `10s`
`requiresCapture`	Payment requires capture. Triggers the `CAPTURE_PENDING` status.	`true` `false`

Payment flows

To simulate different payment flows include the authenticationType key with the required types. Learn how to complete each of the authentication types within mock authenticator here.

Example:

{   "paymentDescriptor":"requiresAuthentication=true;requiresCapture=false;authenticationType=REDIRECT,APP_INTENT,SCAN_CODE,MULTI_FACTOR,APP_NOTIFICATION"
}

Error simulation

Error simulations are used to trigger errors on the different operations.

paymentDescriptor Key	Description	Values
`errorOn`	Specify the operation for the error to occur.	`AUTHORIZE` `AUTHENTICATE` `PROVIDER_CONFIRM` `CAPTURE` `VOID` `REFUND`
`errorMessage`	Specify the free text error message.	Default: `Failed to process payment`

Example:

{
  "paymentDescriptor":"requiresCapture=true;errorOn=AUTHORIZE;errorMessage=Hello World"
}

Authentication types

REDIRECT

You'll receive a requestUrl which allows for the simulation of successful or failed authorization.

SCAN_CODE

You'll receive the codeType QR. Render the QR code and use the PPRO Mock Scanner on your mobile device to scan the QR and select the authorization outcome.

MULTI_FACTOR

No authentication details are returned for MULTI_FACTOR. Submit the verificationCode 777123 to the authorization endpoint in to receive a successful authorization.

POST /v1/payment-charges/{paymentChargeId}/authorizations

{
  "authenticationResult": {
    "type": "MULTI_FACTOR",
    "details": {
      "verificationCode": "777123"
    }
  }
}

Dispute simulation

By leveraging specific keys in the paymentDescriptor and manipulating the transaction amount, you can test end-to-end dispute lifecycles without requiring real-world financial triggers.

Quick start

To enable dispute simulation, include the createDisputeAfterCapture key in your initial payment request:

Endpoint: POST /v1/payment-charges

Key: createDisputeAfterCapture=true

To simulate a delay in dispute creation, include the disputeCreationDelay key as well:

Key: disputeCreationDelay=5min valid inputs are in sec or min

Configuration logic

The Mock Authenticator uses the transaction amount (in subunits units) to determine the type of dispute and the outcome of merchant actions.

1. Dispute type selection

The system automatically selects the dispute category based on the following ranges:

Amount Range (Subunits)	Resulting Action
10,000 – 50,000	A Pre-dispute is created.
All other amounts	A standard Dispute is created.

2. Merchant offer outcomes (Pre-disputes)

When a merchant submits an offer to resolve an active pre-dispute:

Amount Range (Subunits)	Offer Outcome
40,000 – 50,000	The offer is Accepted.
Below 40,000	Default system behavior (Pending).

3. Challenge outcomes

When a merchant chooses to challenge (defend) a dispute or pre-dispute:

Amount Range (Subunits)	Challenge Outcome
3,000 – 4,000	The challenge is LOST.
Other	Default system behavior (Won/Pending).

Usage example

To simulate a Pre-dispute where a merchant's offer will be Accepted, send a request with an amount of 45000:

{
  "amount": 45000,
  "currency": "EUR",
  "paymentMethod": "MOCK",
  "paymentDescriptor": "createDisputeAfterCapture=true;disputeCreationDelay=15sec",
  "okUrl": "https://your-success-url.com",
  "cancelUrl": "https://your-cancel-url.com"
}