Specific parameters for iCard

Besides the general parameters described above for the credit card connection, iCard requires the following additional parameters. An authorisation with 3-D Secure is possible.

Additional parameters for credit card payments

Additional response parameters for credit card payments

Capture / Credit / Reversal

Capture

Captures are possible via a Server-to-Server connection. To perform a capture via a Server-to-Server connection please use the following URL:

Parameters for captures of credit card payments

Response parameters for captures of credit card payments

Capture (Multiple Partial)

Captures are possible via a Server-to-Server connection. In case of multiple partial captures, an extra JSON object needs to be sent. To perform a capture via a Server-to-Server connection please use the following URL:

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "$id": "https://www.computop-paygate.com/schemas/captureInfo.json",
    "title": "captureInfo",
    "examples": [
        // usage: capture=manual|auto|<nn>|Base64-JSON
        {
            "auto": "yes"
        },
        {
            "manual": {
                "final": "no"
            }
        },
        {
            "manual": {
                "final": "no",
                "total": 3
            }
        },
        {
            "manual": {
                "final": "yes"
            }
        },
        {
            "manual": {
                "final": "yes",
                "curIdx": 2,
                "total": 3
            }
        },
        {
            "manual": {
                "final": "yes",
                "total": 3
            }
        },
        {
            "delayed": {
                "hours": 30
            }
        }
    ],
    "description": "captureInfo",
    "properties": {
        "auto": {
            "type": "string",
            "enum": [
                "yes"
            ],
            "additionalProperties": false
        },
        "manual": {
            "type": "object",
            "properties": {
                "final": {
                    "type": "string",
                    "enum": [
                        "yes",
                        "no"
                    ]
                },
                "total": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 99
                },
                "curIdx": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 99
                }
            },
            "required": [
                "final"
            ],
            "additionalProperties": false
        },
        "delayed": {
            "type": "object",
            "properties": {
                "hours": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 99
                }
            },
            "required": [
                "hours"
            ],
            "additionalProperties": false
        }
    },
    "oneOf": [
        {
            "required": [
                "manual"
            ]
        },
        {
            "required": [
                "delayed"
            ]
        },
        {
            "required": [
                "auto"
            ]
        }
    ],
    "additionalProperties": false
}

{
    "$schema": "http://json-schema.org/draft-07/schema#",
    "$id": "https://www.computop-paygate.com/schemas/captureInfo.json",
    "title": "captureInfo",
    "examples": [
        // usage: capture=manual|auto|<nn>|Base64-JSON
        {
            "auto": "yes"
        },
        {
            "manual": {
                "final": "no"
            }
        },
        {
            "manual": {
                "final": "no",
                "total": 3
            }
        },
        {
            "manual": {
                "final": "yes"
            }
        },
        {
            "manual": {
                "final": "yes",
                "curIdx": 2,
                "total": 3
            }
        },
        {
            "manual": {
                "final": "yes",
                "total": 3
            }
        },
        {
            "delayed": {
                "hours": 30
            }
        }
    ],
    "description": "captureInfo",
    "properties": {
        "auto": {
            "type": "string",
            "enum": [
                "yes"
            ],
            "additionalProperties": false
        },
        "manual": {
            "type": "object",
            "properties": {
                "final": {
                    "type": "string",
                    "enum": [
                        "yes",
                        "no"
                    ]
                },
                "total": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 99
                },
                "curIdx": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 99
                }
            },
            "required": [
                "final"
            ],
            "additionalProperties": false
        },
        "delayed": {
            "type": "object",
            "properties": {
                "hours": {
                    "type": "integer",
                    "minimum": 1,
                    "maximum": 99
                }
            },
            "required": [
                "hours"
            ],
            "additionalProperties": false
        }
    },
    "oneOf": [
        {
            "required": [
                "manual"
            ]
        },
        {
            "required": [
                "delayed"
            ]
        },
        {
            "required": [
                "auto"
            ]
        }
    ],
    "additionalProperties": false
}

Parameters for multiple partial captures of credit card payments

Response parameters for multiple partial captures of credit card payments

Credit with reference

Credits (refunds) are possible via a Server-to-Server connection. permits credits which relate to a capture previously activated by  and allows merchants to carry out credits without a reference transaction. This section describes the processing of credits with reference transactions. If you refer to a capture for a Credit, the amount of the Credit is limited to the amount of the previous capture.

To carry out a credit with a reference transaction, please use the following URL:

Parameters for credits of credit card payments

Response parameters for credits of credit card payments

Credit with reference (for multiple captures)

Credits (refunds) are possible via a Server-to-Server connection. permits credits which relate to a capture previously activated by and allows merchants to carry out credits without a reference transaction. This section describes the processing of credits with reference transactions. This action will credit a specific partial capture , using a specific identifier (XID), the same received when performing the capture.

To carry out a credit with a reference transaction done using the multiple partial capture feature, please use the following URL:

Parameters for credits of multiple captures of credit card payments

Response parameters for credits of mutiple captures of credit card payments

Credit without reference

can carry out Credits which do not relate to a previous capture. In this case the credit must be transferred to  as a completely new payment transaction. Please contact the for help in using the described additional functions.

Notice: Please note that credits without reference to a previous capture generate higher costs with your Acquiring Bank. If you are frequently unable to make reference to the capture you should agree this with your Acquiring Bank.

To carry out a Credit without a reference transaction via a Server-to-Server connection, please use the following URL:

Parameters for credits of credit card payments without reference

Response parameters for credits of credit card payments without reference

Reversal

A credit card authorisation lowers the customer's credit line. can reverse an authorisation so that it no longer block the limit any more. Use the following URL:

Notice: Reverse.aspx does not only reverse authorisations, but any LAST TRANSACTION STAGE!! If the last transaction was a capture, Reverse.aspx initiates the reverse, e.g. a credit. Therefore, the utmost caution is urged. Use is at your own risk. We recommend checking the transaction status with Inquire.aspx before using Reverse.aspx.

Parameters for reversals of credit card payments

Response parameters for reversals of credit card payments

Reversal (of partial authorization)

A credit card authorisation lowers the customer's credit line. can after one or multiple partial captures have been completed, offer to reverse part of the still valid authorisation, so that it no longer blocks the remaining amount any more.

Use the following URL:

Notice: The reversal of a still valid authorized amount is specific for iCard and the restriction is that it CAN ONLY BE USED ONCE! More than one attempt will result in an error.

Parameters for partial authorization reversal of credit card payments

Response parameters for partial authorization reversal of credit card payments

Reversal of an authorisation extension

A credit card authorisation is valid for only 7 to 30 days. In order to maintain your payment claim in the case of longer delivery times, enables the automatic renewal of the authorisation. Renewal of the authorisation is also important for instalments or partial deliveries because the outstanding amount is invalid in the case of partial captures.

If you use authorisation renewal,  renews your authorisations until the payment has been captured fully. Amongst other things the customer's card limit is reduced by the authorised amount. In order to restore the card limit again, for example because the order cannot be fully delivered, you need to specifically cancel the authorisation renewal with the following URL:

Notice: CancelAuth cancels only the recurrence of the authorisation. If you wish to unblock the customer's card limit, please reverse the authorisation in accordance with the section above.

Parameters for reversal of an authorisation extension

Result parameters for reversals of an authorisation extension

Credit card payment via POS terminals

To make a credit card payment via a POS terminal (POS: Point of Sale), send the payment request to the following URL:

Parameters for credit card payments via POS terminals

Response parameters for credit card payments via POS terminals

Reversal of POS credit card payments

To reverse the capture of a credit card payment via a stationary terminal, please use the following URL:

Parameters for reversal of credit card payments via POS terminals

Response parameters for reversal of credit card payments via POS terminals

PayNow

Silent Mode for credit cards with SSL and 3-D Secure method

PayNow links the benefits of forms and Server-to-Server connections: As opposed to the  form, where the form is loaded from the  server by calling payssl.aspx, the PayNow form has to be provided by the merchant’s system. The form uses the same parameters as described here below.

In contrast to the  form, the parameters are not forwarded as URL parameters as is the case when calling the payssl.aspx, but as form input parameters. By the way for calling the PayNow.aspx the same parameters can be used as for PaySSL.aspx.

<form action=paynow.aspx>
<input type="hidden" name="MerchantID" value=[mid]>
<input type="hidden" name="Len"        value=[len]>
<input type="hidden" name="Data"       value=[data]>
:
</form>

The credit card data must be transmitted to paynow.aspx with the following parameters:

PayNow parameters for 3-D Secure method

After the customer has entered his credit card data, the payment data is forwarded to the PayNow page, where the further payment processing takes place via 3-D Secure. The form details must be directly forwarded to the PayNow page and may not be transmitted to the merchant’s system! Also, no PCI-relevant data may be transmitted to the PayNow page as additional input parameters!

Batch processing via the interface

Basic information about using Batch files and about their structure can be found in the Batch Manager manual. Within batch processing not alle functions are available which are usually available for the online interface.

Batch calls and answers  

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

Notice: Within Batch process not all functions of online interface are available.

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.

For the connections ECPCC, GMO, Kalixa and SafeCharge the possible actions are limited to Capture, Credit and Reverse.

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

Description of the possible batch versions

The structure for a credit card payment within a Batch file to be submitted is the following:

HEAD,<MerchantID>,<Date>,<Version>
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]
CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,[<FinishAuth,<textfeld1>,<textfeld2>,<approvalcode>]
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>]]
CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>]
CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>, [<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>]
CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>
FOOT,<CountRecords>,<SumAmount>

Example for batch versions:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>

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

The following table describes the individual fields and values used within the data set (record) in the batch file:

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>
CC,Authorize,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>
CC,Capture,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[<textfeld1>,<textfeld2>,<approvalcode>],<Status>,<Code>
CC,AuthSplit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]
CC,Renewal,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,FAILED,<Code>,<Description>,[<PCNr>]
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<Zone>,<transactionID>,<schemeReferenceID>],<Status>,<Code>
CC,Credit,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>[,<FinishAuth>,<textfeld1>,<textfeld2>],<Status>,<Code>
CC,CreditEx,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,[<CCCVC>,]<CCExpiry>,<OrderDesc>[,<textfeld1>,<textfeld2>],<Status>,<Code>
CC,Reverse,<Amount>,<Currency>,<TransID>,(<RefNr>),<PayID>,<Status>,<Code>
FOOT,<CountRecords>,<SumAmount>

Example for batch versions:

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<Status>,<Code>
CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<RTF>,<approvalcode>,<cardholder>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<textfeld1>,<textfeld2>,<transactionID>,<schemeReferenceID>,<Status>,<Code>

CC,Sale,<Amount>,<Currency>,<TransID>,(<RefNr>),<CCBrand>,<CCNr|PCNr>,<CCCVC>,<CCExpiry>,<OrderDesc>,<Zone>,<Status>,<Code>

The following table describes the response parameters which the Batch Manager saves in the Record area for each transaction (standard parameters not explained here, such as <TransID> or <RefNR> and request parameters are returned unchanged and correspond to the call as specified before):

Description of result parameters within the record for Batch files

Cancel authorisation renewals

With a credit card authorisation you get the right to claim a payment. However an authorisation lasts only 30 days which is a problem if you capture a partial amount, for example as part payment for several partial shipments. In order to reproduce your payment request can repeat an expired authorisation automatically.

If an order cannot be delivered or has been cancelled by the customer, it is very important that the automatic authorisations stop. Your customer's card limit will be otherwise reduced permanently because the  continues to charge your customer's card.

Under normal circumstances the  stops the automatic authorisation renewal when the authorised amount has been captured in full. In Batch version 1.4 you can also stop the authorisation renewal manually by changing the payment status. To perform this you submit a capture in your batch file whose amount is under the admissible limit. Since  refuses credit card captures below 1.00 euro, the payment status changes to FAILED in the case of lesser amounts.  therefore renews this authorisation no further. A corresponding capture entry of 0.05 euro’s is shown for example as follows:

Since the amount of 5 cents lies below the minimum amount of 1.00 euro,  refuses the capture with the error message MinValue. The payment status changes to FAILED and the authorisation renewal is stopped.