The PAYONE platform provides an asynchronous way of notifying your system of changes to a transaction. We call these notifications "TransactionStatus".

As you can see, our platform informs you of every successful action with a TransactionStatus notification.

PMI Configuration

You can configure the TransactionStatus Endpoint of your system in your payment portal configuration.

Use Cases

Redirect Payment Methods

Many of today's payment methods use redirects to send customers to their site for login and finalization of the checkout. After completing the payment on the third-party site, the customer is redirected to a URL you can specify via the successurl parameter. However, fraudsters could just guess the successurl and open the URL without a successful payment.

The TransactionStatus system can help prevent this kind of fraud by sending a TransactionStatus notification before redirecting the customer to the successurl.

Note the "appointed" message prior to the redirect.

Chargeback Processes

Some payment methods (like SEPA Direct Debit or PayPal) offer chargeback processes, where customers can trigger reverse cashflow after an allegedly fraudulent transaction. This mechanism can of course be used to obtain goods and then charge back the money by fraudsters.

Our TransactionStatus notification system can send notifications in case such a chargeback is triggered, allowing you to keep up with any action that's happening to a past transaction.

Technical Specification

PAYONE to your Endpoint

Our TransactionStatus notifications are sent as https POST messages from the IP range with the user agent "PAYONE FinanceGate"

  • Status messages from PAYONE to merchant's server are always ISO-8859-1 encoded.
  • Status messages are posted with application/x-www-form-urlencoded

Example Request
key=your key as md5 hash e.g. "3c6e0b8a9c15224a8228b9a98ca1531d"
street=J%E4gerweg 12

Synchronous Reply

your endpoint will have to reply synchronously with either TSOK or SSOK (just 4 characters, no html)

  • No other characters may be issued with this character string “SSOK”/”TSOK”
  • Do not return an error without gathering information about this error.
  • The request must be answered with SSOK (for SessionStatus) / TSOK (for TransactionStatus). The connection timeout is set to 10 seconds and can not be extended.
  • Make sure the request is always answered with an SSOK (for SessionStatus) / TSOK (for TransactionStatus).
  • The request is repeated a maximum of 12 times and for a maximum of 48 hours. The first retry is started after about one hour and the retry time is increasing. After 48 hours the request will not be repeated any more.
  • The answer does only confirm receipt of the SessionStatus, the evaluation can and should follow asynchronously to receiving the answer.
  • If a specific request shall not be processed, issue an SSOK (for SessionStatus) / TSOK (for TransactionStatus) anyway to prevent the request from interfering with the processing of other requests.
  • Without the return of an SSOK (for SessionStatus) / TSOK (for TransactionStatus) you will not receive any further status reports for that subscription / payment process.
  • Please verify received status responses before processing, i.e.: check whether portalid, aid and key do match your expected credentials. If credentials do not match your expected values then dismiss status response.

See Parameter for the TransactionStatus query and Samples of TransactionStatus query for deeper info

  • No labels