Introduction

Getting Started with TransactionStatus Notifications

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 185.60.20.0/24 with the user agent "PAYONE FinanceGate"

---end

  • 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"
txaction=appointed
portalid=1234567
aid=12345
clearingtype=cc
notify_version=7.4
txtime=1633361234
currency=EUR
userid=12345678
mode=test
price=19.99
txid=987654321
reference=10001_2
sequencenumber=0
firstname=Max
lastname=Mustermann
street=J%E4gerweg 12
zip=12345
city=Berlin
email=mmustermann@payone.com
country=DE
cardexpiredate=2505
cardtype=V
cardpan=411111xxxxxx1111
transaction_status=completed
balance=0.00
receivable=0.00

---end

Synchronous Reply

---end

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.

---end

Example Reply
TSOK

---end

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

---end

Introduction

Parameter for the TransactionStatus

According to the configuration of your payment portal you will receive the data and the status for each payment process via the URL you have submitted. The data transfer is based on simple HTTP-POST request (key/value pairs).

The TransactionStatus is sent from the following IP addresses: 185.60.20.0/24 (i.e. 185.60.20.1 to 185.60.20.254). Please configure your firewall to allow incoming packets from these IP addresses.

TransactionStatus

HTTP request from PAYONE to the merchant's server

Account Parameters
key
required
Format AN..32
Payment portal key as MD5 value (The key hash values is currently given as MD5. This currently still remains with MD5 and is subject to change in future to SHA2-384.)
txaction
required

"appointed", "capture", "paid", "underpaid", "cancelation", "refund", "debit", "reminder",
"vauthorization", "vsettlement", "transfer", "invoice", “failed”

(See explanation below)

transaction_status
optional
“completed”, “pending”
notify_version
optional
7.3 without “notify_version” and without “transaction_status”
7.4 with “notify_version” and with “transaction_status” (completed/pending)
7.5 with txaction “failed”
7.6

with “transaction_status=pending” and “reasoncode”

---end

mode
required
test Test mode
live Live mode1

---end

portalid
required
Format NUMERIC..7
Payment portal ID
aid
required
Format NUMERIC..6
Sub account ID
clearingtype
required
Format AN..32
elv Debit payment
cc Credit card
vor Prepayment
rec Invoice
cod Cash on delivery
sb Online bank transfer
wlt e-Wallet
fnc Financing

---end

txtime
required
Format NUMERIC..11
Initiating payment process (Unix timestamp)
currency
required
Format LIST
Currency (ISO 4217)
userid
required
Format NUMERIC..12
Debtor ID (PAYONE)
customerid
optional
Format AN1..20
Merchant's customer ID
param
optional
Format AN..255
Individual parameter that was, where applicable, submitted while payment was initiated

---end

Parameter (personal data)
firstname
optional
Format AN..50

First name (optional if company is used)

lastname
required
Format AN..50

Surname

company
optional
Format AN..50

Company name

street
optional
Format AN..50

Street number and name

zip
optional
Format AN..10

Postcode

city
optional
Format AN..50

City name

country
required
Format LIST

Country (ISO 3166)

---end

Parameter (Delivery-Address)
shipping_firstname
optional
Format AN..50

First name (optional if company is used)

shipping_lastname
optional
Format AN..50

Surname (optional if company is used)

shipping_company
optional
Format AN..50

Company

shipping_street
optional
Format AN..50

Street number and name

shipping_zip
optional
Format AN..10

Postcode

shipping_city
optional
Format AN..50

City

shipping_country
optional
Format LIST

Country (ISO 3166)

email
optional
Format AN..254

Email address

shipping_street
optional
Format AN..50

Street number and name

---end

Parameter (status message of a payment process)
txid
required
Format NUMERIC..12

Payment process ID (PAYONE)

reference
required
Format AN..20

Merchant reference number for the payment process

sequencenumber
required
Format NUMERIC..2

Sequence number at the time of the event for this payment process (0..n)

price
required
Format NUMERIC..10,2

Payment request (in largest currency unit! e.g. Euro)

receivable
optional
Format NUMERIC..10,2

Total payment request (in largest currency unit! e.g. Euro); not set for encashment reminder status information without paid amount

balance
optional
Format NUMERIC..10,2

Balance of transaction account (in largest currency unit! e.g. Euro) ; not set for encashment reminder status information without paid amount

Negative amount: positive balance

Positive amount: payment request

failedcause
optional
Format LIST

Reason for return debit note or incorrect collection (see Reasons for return debit notes (failedcause))

errorcode
optional
Format NUMERIC..4

Errorcode in case of txaction=”failed”

reasoncode
optional
Format AN..10

Reasoncode in case of transaction_status=”pending”. Further details for transactionhandling see payment addon documentation.

Sent only with “notify_version=7.6”

Additional parameter Contract for the status message of a payment process
productid
required
Format NUMERIC..7

ID for the offer 

accessid
required
Format NUMERIC 3..12

Access ID 

expiretime
optional
Format NUMERIC..12

Unix Timestamp when access expires

---end

Additional parameter for payment type debit payment
bankcountry
optional
Format LIST

Account type/ country

bankaccount
optional
Format AN..26

Account number (masked)

bankcode
optional
Format AN..11

Sort code

bankaccountholder
optional
Format AN..35

Account holder

---end

Additional parameter for payment type debit payment (only for authorization with appointed and only if “due_time” is not specified)
iban
optional
Format AN..35

International Bank Account Number (masked)

bic
optional
Format AN..11

Bank Identifier Code

mandate_identification
optional
Format AN..35

Used mandate_identification

creditor_identifier
optional
Format AN..35

Merchant’s creditor identifier

clearing_date
optional
Format NUMERIC..8

clearing date (format YYYYMMDD)

clearing_amount
optional
Format NUMERIC..10

Payment request (in smallest currency unit! e.g. cent)

Additional parameter for payment type credit card
cardpan
required
Format NUMERIC..19

Card number

cardtype
required
Format LIST
V Visa
M MasterCard
A American Express
D Diners / Discover
J JCB
O Maestro International
B Carte Bleue
P China Union Pay

---end

Card type

cardexpiredate
required
Format NUMERIC..4

Expiry date YYMM

cardholder
optional
Format AN..35

Name of cardholder

cardholder_info
optional
Format AN..128

Message provided by the Issuer in regards to 3DS processing. It provides valuable opportunity for the Issuers to inform the Cardholders why their payment can not proceed, and guide them to the necessary corrective action.

Currently, it is optional for Merchants to display this text to Cardholders in EMV 3DS 2.1, but becomes mandatory in EMV 3DS 2.2.

It is always optional for Issuers to use it, so the value might be omitted.

---end

Additional parameter for payment type paypal
provider_payerid
required
Format AN..13

Unique PayPal Customer Account identification number.

Additional parameter for payment type iDeal
customer_bankaccountholder
optional
Format AN..35

Customers bank account holder

customer_iban
optional
Format AN..35

Customers IBAN

customer_bic
optional
Format AN..11

Customers BIC

---end

Additional parameter for payment type Klarna
clearing_bankaccountholder
optional
Format AN..35

Recipient bank account holder

clearing_bankcountry
optional
Format LIST

Recipient account type/ country (e.g. DE, AT, etc.)

clearing_bankaccount
optional
Format AN..26

Recipient bank account

clearing_bankcode
optional
Format AN..11

Recipient sort code

clearing_bankiban
optional
Format AN..35

Recipient IBAN

clearing_bankbic
optional
Format AN..11

Recipient BIC

clearing_bankcity
optional
Format AN..50

Recipient city or bank

clearing_bankname
optional
Format AN..50

Recipient bank name

clearing_legalnote
optional
Format AN..500

Note to claim assignment

clearing_duedate
optional
Format NUMERIC..8

Due date of payment (format YYYYMMDD)

clearing_reference
optional
Format AN..50

Reference

clearing_instructionnote
optional
Format AN..200

Note to payment handling

Additional parameter Collect (txaction=reminder) for the status message of a payment process
reminderlevel
required
Format LIST
reminderlevel Description
1..4

Dunning level 1-4

5

Encashment

A

Dunning procedure ended

S

Dunning procedure begins

M

Dunning proposal list

I

Encashment proposal list

0

Dunning procedure completed

---end

Customer's reminder status

encashment_statuscode
optional
Format AN..20

Internal status code of the encashment agency, if provided by the encashment agency.

encashment_statuslongtext
optional
Format AN..255

Free text: if the encashment agency has reported a long text (detailed information) on the status

---end

Parameter Invoicing (txaction=invoice)
txid
required
Format NUMERIC(9..12)

Payment process ID (PAYONE)

reference
required
Format AN..20

Merchant reference number for the payment process

sequencenumber
required
Format NUMERIC..2

Sequence number at the time of the event for this payment process (0..n)

invoiceid
required
Format AN..20

Merchant's invoice number

invoice_grossamount
required
Format NUMERIC..10,2

Gross invoice amount

invoice_date
required
Format NUMERIC..8

Invoice date (format YYYYMMDD)

invoice_deliverydate
optional
Format NUMERIC..8

Delivery date (format YYYYMMDD)

invoice_deliveryenddate
optional
Format NUMERIC..8

Delivery period end date (format YYYYMMDD)

Parameter Billing (txaction=vauthorization/vsettlement)
vaid
required
Format NUMERIC..8

Billing account ID (module billing)

balance
required
Format NUMERIC..10,2

Balance of billing account (in largest currency unit! e.g. Euro)

Negative amount: positive balance

Positive amount: payment request

vreference
required
Format AN..20

Merchant's transaction reference number 

(This is the reference for the corresponding payment process for a vsettlement)

vxid
required
Format NUMERIC..12

Billing account entry ID

---end

Parameter Billing (txaction=vsettlement)
txid
optional
Format NUMERIC(9..12)

Corresponding payment process ID

sequencenumber
optional
Format NUMERIC..2

Sequence number of settled payment process ID

settled_vxid[n]
optional
Format NUMERIC..12

Array of settled vxid's starting with n=0.

Array will not be sent if more than 500 vxid's are settled.

Host: api.pay1.de
Content-Type: application/x-www-form-urlencoded
Edit your payload here
key1=value1
key2=value2
key3=value3
...
Edit your response here
key1=value1
key2=value2
key3=value3
...

 ---

Please note that new parameters may be added at any time without previous notice. Therefore, you should use the parameter name for the evaluation and not the sequence, which may be subject to change at any time!

---end

Expected reply to the request

As a reply to the request, the string "TSOK" is expected. Each request is repeated in a 1 to 6 hour cycle until it is answered with "TSOK". This procedure ensures that all requests will be processed by your system. Simply issue the "TSOK" in a script via the "print" command. Make sure that this character string is the first that is printed from this script, e.g. print ("TSOK"); 

List of events (txaction)

With each payment process status change you receive a request. The last event is submitted to you via the parameter "txaction". The status of the request is provided via the balance of the payment process (parameter "balance") and the amount of the request (parameter "receivable").

txaction Description
appointed

Via "appointed" you are informed about the successful initiation of the payment process. This request is affected immediately after the first successful booking.

The new parameter “transaction_status” indicates whether the event “appointed” is pending or completed.
-> see list of status (transaction_status)
capture

Via "capture" you are informed about the booking of a request or the collection of your reserved amount. The amount of the request (receivable) is increased in this case. If no settlement of balances occurs, the balance changes as well.

paid

Via "paid" you are informed that the booking has been processed by the credit institution or that the customer has paid the invoice in full. The balance for the request in this case is smaller than or equal to zero.

underpaid

Via "underpaid" you are informed about an underpayment. The balance for the request in this case is greater than zero.

cancelation

Via "cancelation" you are informed that a payment process has resulted in a return debit note. In the case of electronic direct debit processes (ELV) insufficient funds in the account may also be the cause. The balance for the request in this case is greater than zero.

refund

Via "refund" you are informed if an amount has been refunded. The amount of the request (receivable) is decreased in this case.

debit

Via "debit" you are informed about the booking of a request/credit for a request. The amount of the request (receivable) changes in this case. If no settlement of balances occurs, the balance changes as well.

transfer

Via "transfer" you are informed if an amount has been transferred. The amount of the open balance (balance) changes in this case.

reminder

Attention: This request must be activated by PAYONE.

Via "reminder" you are informed about the current status of the dunning procedure.

vauthorization

Attention: This request must be activated by PAYONE.

Via "vauthorization" you are informed about a booking affected into a billing account (module billing).

vsettlement

Attention: This request must be activated by PAYONE.

Via "vsettlement" you are informed about a settlement effected on a particular billing account (module billing).

invoice

Attention: This request must be activated by PAYONE.

Via "invoice" you are informed that an invoice or a credit voucher has been created.

failed

Via "failed" you are informed that the booking has finally failed. No further actions are possible

---end

     

List of status (transaction_status)

Via "pending" you are informed that the payment transaction is (still) pending at the external payment processor. The following transaction status may be “pending” (again), “completed” (external payment processor completed the current transaction successfully).

With each payment process status change you receive a request. The last event is submitted to you via the parameter "txaction".

The parameter “transaction_status” is currently introduced with event-txaction “appointed” only. Other event-txaction with parameter “transaction_status” may follow (e.g. “paid”, “debit”, …).

Please note:

  • The parameter “transaction_status” is optional and not available for all payment transactions (“txaction”) and all payment types (as not all payments and processors do support “pending” / “completed”).
  • It may happen that you will receive two times the same txaction (e.g. “appointed”). First with “pending” and then with “completed”. 

transaction_status Description
pending

The event indicated by “txaction” is pending and may change later. i.e. an event “appointed/pending” (txaction/transaction_status) indicates that the payment is pending and in process at the 2nd payment processor.

Another event may follow to inform change of status by txaction e.g. “appointed/completed”, “failed/completed”.

Also another “appointed/pending” may follow to indicate that transaction is still pending.

completed

Indicates that the event itself has reached final status.

However a new “txaction” (e.g. “paid”, “cancelation”, …) may follow to inform of change of status.

The new “txaction” can then be “paid/pending”, “paid/completed”, … or “failed/completed”.

Parameter for SessionStatus query

According to the configuration of your payment portal you will receive access status changes for accesses to your premium sector. You will only receive these status messages with payment portals of the "Access" version. You can use them to protect your premium sector or to receive information about a subscription. The data is submitted to the URL specified in the merchant area. The data transfer is based on simple HTTP-POST request (key/value pairs).

The SessionStatus is sent from the following IP addresses: 185.60.20.0/24 (i.e. 185.60.20.1 to 185.60.20.254). Please configure your firewall to allow incoming packets from these IP addresses.

SessionStatus

HTTP request from PAYONE to the merchant's server
key
required
Format AN..32

Key can be selected freely (see options payment portal) as MD5 value (The key hash values is currently given as MD5. This currently still remains with MD5 and is subject to change in future to SHA2-384.)

clearingtype
required
Format LIST
elv Debit payment
cc Credit card
vor Prepayment
rec Invoice
sb Online bank transfer

---end

Type of payment used for this access.

serverip
optional
Format LIST

-> this parameter may be removed in future.

accessid[x]
required
Format NUMERIC 3..12

Access ID (PAYONE)

action[x]
required
Format LIST

Event, which refers to one customer each.

"add" , "remove", "abocancel", "renew "cancel_reversal", "lock", "unlock" (see below)

portalid[x]
required
Format N..7

Payment portal ID

productid[x]
required
Format N..7

ID for the offer

expiretime[x]
required
Format N..12

Unix timestamp at which access expires

userid[x]
required
Format N..12

Debtor ID (PAYONE)

customerid[x]
optional
Format AN 1..20

Merchant's customer ID

accessname[x]
optional
Format AN..32

Customer's user name

accesscode[x]
optional
Format AN..32

Customer's password

ip[x]
optional
Format AN..15

Customer IP

param[x]
optional
Format AN..15

Individual parameter

---end

Common Parameters
key
N..x
Numeric value (x characters maximum)
AN..x
Alphanumeric value (x characters maximum)
[x]
In this manner changes for several customers can be submitted simultaneously in one request.
[x] = position number, e.g. [0],[1],...)

---end

Host: api.pay1.de
Content-Type: application/x-www-form-urlencoded
Edit your payload here
key1=value1
key2=value2
key3=value3
...
Edit your response here
key1=value1
key2=value2
key3=value3
...

 ---

Please note that new parameters may be added at any time without previous notice. Therefore, you should use the parameter name for the evaluation and not the sequence, which may be subject to change at any time!

---end

Expected reply to the request:

As a reply to the request, the string "SSOK" is expected. Each request is repeated in a 1-hour cycle until it is answered with "SSOK". This procedure ensures that all requests will be processed by your system. Simply issue the "SSOK" in a script via the "print" command. Make sure that this character string is the first that is printed from this script, e.g. print ("SSOK");

Sequence of events

After the start of the initial term an "add" request is deployed to your system. Different pieces of information about this customer are submitted (see above). After the access has expired, you will receive a "remove" request.

List of events (action)

With each access status change you receive a request. Via the "action" variable you receive information about the status of the access.

Action Description
add

An access portal has been opened.

remove

Access has expired and will not be renewed.

renew

Access was renewed/reduced (e.g. renewal of a subscription).

abocancel

The customer has cancelled the subscription for this access portal.

lock

Access has been blocked.

unlock

Access has been unblocked.

cancel_reversal

The termination of the subscription has been revoked.

---end

Explanation of price, balance, receivable

Field Description Beschreibung
price

Value of the initial claim

Wert der initialen Forderung

balance

The outstanding balance of this transaction:

  • negative: Customer has a claim against merchant, e.g. merchant received money without effort
  • positive: Merchant has a claim against the customer

Enthält die offene Forderung der Transaktion:

  • negative: Endkunde erwartet Geld vom Händler (Überzahlung)
  • positive: Händler erwartet Geld vom Endkunden
receivable

Account balance for the transaction.

  • With a “preauthorization” the value “receivable” is not set as the merchant did not provide the service yet (e.g. delivering goods).
  • With type of payment “cash In advance” the value “receivable” is not set as the merchant will only provide its service when money has arrived.

Aktuelle offene Forderung für die Transaktion:

  • Bei einer “preauthorization” ist der Wert von “receivable” nicht gesetzt, da die Forderung erst durch den “Capture” in das System kommt. (z.B. Warenversand).
  • Bei Vorkasse ist der Wert von “receivable” nicht gesetzt, da der Händler seiner Pflicht erst nachkommt, wenn das Geld gezahlt wurde.

---end

---end

Samples of TransactionStatus

---end

Samples of TransactionStatus sent for a credit card payment
EXAMPLE 1:
https://shop.domain.shop/test/p1.php?key=xxxxx&txaction=appointed&portalid=2000001&aid=10001&clearingtype=cc&notify_version=7.4&txtime=1533547771&currency=EUR&userid=100000001&accessname=&accesscode=&param=&mode=test&price=1.00&id[1]=1_1&pr[1]=1.00&no[1]=1&de[1]=item+description&ti[1]=&va[1]=19.00&txid=285115882&reference=1533547769340&sequencenumber=0&company=&firstname=Max&lastname=Musterm%E4nnchen&street=Fraunhoferstra%DFe+2-4&zip=24118&city=Kiel&email=test.test%40test.com&country=DE&shipping_company=&shipping_firstname=Max&shipping_lastname=Muster&shipping_street=FRAUNHOFER+STR+2-4&shipping_zip=24103&shipping_city=Kiel&shipping_country=DE&cardexpiredate=2012&cardtype=V&cardpan=401200xxxxxx1112&transaction_status=completed&balance=1&receivable=1

EXAMPLE 2:
https://shop.domain.shop/test/p1.php?key=xxxxx&txaction=invoice&portalid=2000001&aid=10001&clearingtype=cc&notify_version=7.4&txtime=1533547771&currency=EUR&userid=100000001&accessname=&accesscode=&param=&mode=test&price=1.00&txid=285115882&reference=1533547769340&sequencenumber=0&company=&firstname=Max&lastname=Musterm%E4nnchen&street=Fraunhoferstra%DFe+2-4&zip=24118&city=Kiel&email=test.test%40test.com&country=DE&shipping_company=&shipping_firstname=Max&shipping_lastname=Muster&shipping_street=FRAUNHOFER+STR+2-4&shipping_zip=24103&shipping_city=Kiel&shipping_country=DE&cardexpiredate=2012&cardtype=V&cardpan=401200xxxxxx1112&invoiceid=RG-285115882-0&invoice_grossamount=1&invoice_date=20180806

EXAMPLE 3:
https://shop.domain.shop/test/p1.php?key=xxxxx&txaction=paid&portalid=2000001&aid=10001&clearingtype=cc&notify_version=7.4&txtime=1533547771&currency=EUR&userid=100000001&accessname=&accesscode=&param=&mode=test&price=1.00&id[1]=1_1&pr[1]=1.00&no[1]=1&de[1]=item+description&ti[1]=&va[1]=19.00&txid=285115882&reference=1533547769340&sequencenumber=0&company=&firstname=Max&lastname=Musterm%E4nnchen&street=Fraunhoferstra%DFe+2-4&zip=24118&city=Kiel&email=test.test%40test.com&country=DE&shipping_company=&shipping_firstname=Max&shipping_lastname=Muster&shipping_street=FRAUNHOFER+STR+2-4&shipping_zip=24103&shipping_city=Kiel&shipping_country=DE&cardexpiredate=2012&cardtype=V&cardpan=401200xxxxxx1112&balance=0&receivable=1

---end

Sample authorization - CC
Merchant’s request HTTP request from PAYONE to the merchant's server

Seq-

No

Time

TX-Action/ transaction_state

Seq-

No

price

balance

receivable

Request authorization

CC amount=15061

0

T=0

appointed/ completed

0

150.61

150.61

150.61

0

+4

min

paid

0

150.61

0

150.61

---end

Sample authorization - ELV with cancelation
Merchant has configured:
  • Due time ELV = 7 days
  • Fee 1. reminder = 0,00 Euro after 7 days
  • Fee 2. reminder = 1,00 Euro after 7 days
  • Fee 3. reminder = 2,40 Euro after 7 days
  • Encashment transfer = 5,00 Euro after 7 days
  • TxStatus without reminder-information

Merchant’s request HTTP request from PAYONE to the merchant's server Comment

Seq-

No

Time

TX-Action/ transaction_state

Seq-

No

price

balance

receivable

Request authorization

ELV amount=4612

0

T=0

appointed/ completed

0

46.12

46.12

46.12

Merchant initiates payment via SEPA direct debit

+15 min

paid

0

46.12

0

46.12

PAYONE platform has processed direct debit

+7

days

cancelation

0

46.12

54.72

54.72

PAYONE platform has detected a return debit note initiated by end customer and added bank charges of 8,60 EUR and 0 Euro dunning fee

+14

days (7+7)

debit

1

46.12

55.72

55.72

PAYONE platform processed dunning note and added 1,00 Euro dunning fee

+21

days

debit

2

46.12

57.72

57.72

PAYONE platform processed dunning note and added 2,00 Euro dunning fee

+28

days

debit

3

46.12

62.72

62.72

PAYONE platform processed dunning note and added 5,00 Euro dunning fee

---end

Sample authorization - WLT (with pending)
Merchant’s request HTTP request from PAYONE to the merchant's server Comment

requires „notify_version=7.6“

Seq-

No

Time

TX-Action/ transaction_state

Seq-

No

price

balance

receivable

Request authorization

WLT amount=111

0

T=0

appointed/pending

0

1.11

0

0

Server API-response "status=PENDING" (requires api_version=3.11)

and “reasoncode=903” indicating Timeout at service provider

0

+10 sec

appointed/completed

0

1.11

1.11

1.11

0

+6 min

paid

0

1.11

0

1.11

---end

Sample preauthorization - capture - CC
Merchant’s request HTTP request from PAYONE to the merchant's server Comment

Seq-

No

Time

TX-Action/ transaction_state

Seq-

No

price

balance

receivable

Request preauthorization

CC amount=2950

0

T=0

appointed/pending

0

29.50

0

0

Request capture

1

+2 hours

paid

1

29.50

0

29.50

Sample preauthorization - capture - REC with credit note
Merchant has configured:
  • Due time Invoice = 14 days
  • Fee 1. reminder = 0,00 Euro after 3 days
  • Fee 2. reminder = 2,00 Euro after 10 days
  • Fee 3. reminder = 4,00 Euro after 10 days
  • TxStatus without reminder-information

Merchant’s request HTTP request from PAYONE to the merchant's server Comment

Seq-

No

Time

TX-Action/ transaction_state

Seq-

No

price

balance

receivable

Request preauthorization

REC amount=11500

0

T=0

appointed/pending

0

115.00

0

0

Merchant initiates payment via payment type invoice

Request capture

1

+1 day

capture

1

115.00

115

115

Merchant has delivered ordered items

+27 days

(14+3+10)

debit

2

115.00

117

117

PAYONE platform generates reminder document and added 2 Euro dunning fee

+10 days

debit

3

115.00

121

121

PAYONE platform generates reminder document and added 4 Euro dunning fee

PMI: credit note by 15,00 Euro

4

+13 days

debit

4

115.00

106

106

PAYONE platform processed credit note initiated via PMI

---end

preauthorization - capture - WLT (with pending)
Merchant’s request HTTP request from PAYONE to the merchant's server Comment

Seq-

No

Time

TX-Action/ transaction_state

Seq-

No

price

balance

receivable

Request preauthorization

WLT amount=1561

0

T=0

appointed/pending

0

15.61

0

0

Request capture

WLT amount=1561

1

+6 seconds

capture/pending

0

15.61

0

15.61

Server API-response "status=PENDING" (requires api_version=3.11)

+15 seconds

capture/-

0

15.61

15.61

0

---end