SUCCEEDED after FAILED

By their design, some payment schemes can return a SUCCEEDED status after a FAILED status. PPRO asks you to account for this case (and all related logic on the consumer side) during integration.

This can occur when a payment scheme has a technical issue that leads to a delayed notification to PPRO. This in turn leads PPRO to flag a transaction as FAILED that will ultimately succeed. In an effort to ensure that the reporting is correct, PPRO always updates the transaction status to the correct status as provided by the scheme. The reverse can never occur, where a transaction fails after initial success.

Remote / Local Error Behavior

In a live environment, do not continually resend transactions if the PPRO API returns a remote or local error. We recommend to catch the API response and send a new transaction once normal traffic has resumed. Do not repeatedly send the same transaction when receiving the same result.

If you cannot avoid retrying, then throttle calls to PPRO to approximately no more than one call per every ten seconds. For example, instances of scheme downtime could lead to a remote error whereby the scheme is not down for PPRO, but for all parties integrated into the scheme. PPRO communicates these downtimes as fast as possible.

Test System Quotas

The test system is not designed as a load testing platform. PPRO does not allow bulk traffic on its test host. The following quotas are in place to prevent abuse of the test system:

Transaction Type	# of attempts allowed per 12-hour period	Notes
New Payment (cash-in) Transactions	500	Regardless of final transaction status; count is # of initialized transactions
Get Transaction Status	1000
Get Transaction Status by MerchantTXID	50
Refund	100	Regardless of final transaction status; count is # of initialized transactions
Get Refund Status	200
Get Refund Status by Merchant RefundID	30

The quota resets twice a day at 00:00 UTC and 12:00 UTC. These quotas do not apply to the live host.

Transaction Status Pull Behavior

PPRO’s environment is designed to push a transaction status once we know of a new status for a given transaction. Therefore, there is no need to poll the PPRO system manually for a status update, as there will have been no change until a notification has been pushed. If a listener script for the transaction status fails, PPRO will reattempt delivery 191 more times – one attempt every 15 minutes.

SPECOUT Handling

The PPRO API transmits informational SPECOUT parameters specific to the payment method. These are documented in the specific payment method entries. However, SPECOUTs are subject to change. PPRO never removes SPECOUTs if a scheme no longer transmits the relevant data. If a payment method no longer transmits data for a SPECOUT, PPRO will inform you as quickly as possible and start transmitting filler data.

An optimal integration to PPRO can handle both the removal and addition of SPECOUTs. This means not having logic that can fail if a SPECOUT changed in content type, was newly added or, in the very unlikely event, was removed from a payment method.