interface

Payment with TWINT over  form interface

To make a TWINT payment over  form, please use the following URL:

Parameters for TWINT

 Please note that the final notification may be delayed by approx. 30-35 minutes or up to 60-65 minutes if the customer completes the payment and closes the browser immediately afterwards. The reason for this is that the payment status can only be read in via the browser callback and if this is not done, the status is requested downstream by our at the above-mentioned interval. Due to the missing callback, the redirect to the URLSuccess/URLFailure is also not processable.

Return parameters for URLSuccess, URLFailure and URLNotify with TWINT

Capture

If your  MID isn't configured for Sale operation, every initial TWINT payment (call to twint.aspx) should be confirmed using capture.aspx endpoint or canceled via reverse.aspx.

Captures (or confirmations in terms of TWINT) are possible via a Server-to-Server connection. To carry out a Capture via a Server-to-Server connection, please use the following URL:

Parameters for captures with TWINT via socket connection

Response parameters for captures with TWINT via socket connection

Reversal

Reversals are possible via a Server-to-Server connection. In order to cancel a payment via a server-to-server communication, please use the following URL:

Parameters for reversals with TWINT via socket connection

Response parameters for reversals with TWINT via socket connection

Credit with reference

Notice: Please note that TWINT limits refunds in the production environment as well as on the test system – production mode: 180 days / test mode: 7 days.

Parameters for credit payments with TWINT via socket connection

Response parameters for credit payments with TWINT via socket connection

Batch processing via the interface

This section describes the parameters which must be transferred within the data set (Record) for executing a Twint payment and information can be found within the response file about the payment status.

For Batch calls there must be considered batch versions, from which optional parameters depend. All version designations starting with „2.“ pertain calls for a group of enterprises. That means within a batch file for a particular MerchantID can be transferred transactions for other merchants with a separate Sub-MID

Following table gives an overview of all batch versions that are possible for a specific action an their specialities:

Description of the possible batch versions

The structure for a Twint payment within a Batch file to be submitted is as follows:

HEAD,<MerchantID>,<Date>,<Version>
Twint,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>,)<PayID>
Twint,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>,)<PayID>
Twint,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>,)<PayID>
FOOT,<CountRecords>,<SumAmount>

Example for Master MID function:

HEAD,[Master]MerchantID,Date,2.x
Type,Action,[Slave]MID,Amount,Currency,TransID,Data (depends on Action)
FOOT,CountRecords,SumAmount

Description of fields within the record for Batch files

The record area within the response file for Batch transactions looks as follows:

HEAD,<MerchantID>,<Date>,<Version>
Twint,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>,)<PayID>,<Status>,<Code>
Twint,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>,)<PayID>,<Status>,<Code>
Twint,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>,)<PayID>,<Status>,<Code>
FOOT,<CountRecords>,<SumAmount>

Description of result parameters within the record for Batch files