Available Transaction-Based Operations

Available Transaction-Based Operations

approveReversal

approveReversal is the operation that cancels an approval and can be done only when the approval has not yet been debited.

Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber
No additional response parameters are returned.

deposit

deposit is executed by you if an order of a consumer has been accepted. This operation causes an approval to be converted into a deposit and a daily closing is automatically opened when there is no one already open for this payment method and currency.

Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber,amount,currency

deposit can be reversed with the depositReversal when the corresponding daily closing has not yet been done and the financial services provider and the payment method support it.

If you want to do split capture e.g. if you want to partially ship the items in your consumers shopping basket, you need to send some additional information about the items you want to ship and deposit, so use additional optional request parameters for the shopping basket.

Shopping Basket Data

For some payment methods information about the basket items on each deposit is required, especially if the items are shipped in multiple shipments and each shipment is separately deposited.
The following basket parameters are available.

Following parameters are optional, either all parameters need to be set or none, except for basketItem(n)Description and basketItem(n)ImageUrl which remain optional.

depositReversal

depositReversal either cancels a deposited payment or converts a deposited payment into an approved payment. This operation can only be done before the day-end closing has been executed.

Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber,paymentNumber

Additional required request parameters for depositReversal.

No additional response parameters are returned.

getOrderDetails

getOrderDetails returns all details for a given order including all possible operations, corresponding payments and credit notes.

Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber

Additional required request parameters for getOrderDetails.

Within the additional response parameters there are some parameters that will occur more than once, so we use the letters n and m as placeholders for digits. Currently, n is always 1 because getOrderDetails returns only one order and m indicates that there may be more than one payment or credit object returned.

Feature-Specific Parameter

Response parameter enhances the result data of the payment process regarding specific features and functions.

Parameter Data type Description

payment.{n}.{m}.instrumentCountry

Alphabetic, fixed 2.

Country of the consumer which has been detected and returned by the financial service provider.

paymentType

The parameter paymentType returns the technical property used for the transaction.

Value Description

AFTERPAY

AfterPay

CCARD

Creditcard

CCARD-MOTO

Creditcard MOTO

CRYPTO

Salamantex

EPS

EPS-Überweisung

ELV

Hobex SEPA

INVOICE

Invoice

MAESTRO

Mastercard Maestro

PAYPAL

PayPal

PSC

Paysafecard

SOFORTUEBERWEISUNG

Klarna Sofort

SEPA-DD

Direct Debit

Return Message PENDING

If the getOrderDetails is carried out for order numbers that are still in progress no statement on the actual or final order state may be retrieved and the message PENDING is returned:

Message errorCode paySysMessage Status

The final state of the transaction could not yet be determined.

30014

(15/30761)-No payer assigned to EC token.

3

Currently, error code 30014 is supported by those payment methods for which the pendingUrl is required or recommended.

Return Message REJECTED

If the operation getOrderDetails is carried out, payments in status REJECTED return the following result:

Message errorCode paySysMessage Status

The financial institution has declined the transaction. Check the data you have entered.

20003

WCP: Auth: Verification failed.

2

paySysMessage depends on the relevant financial service provider response.

recurPayment

recurPayment uses the payment information available from a previous order to create a new order and a new payment attempt.

Required order of the parameter values when computing the fingerprint
customerId, shopId, toolkitPassword, secret, command, language, orderNumber, sourceOrderNumber, autoDeposit, orderDescription, amount, currency, orderReference, customerStatement, mandateId, mandateSignatureDate, creditorId, dueDate, transactionIdentifier, useIbanBic, merchantTokenizationFlag, periodicType
According to credit card company requirements for risk minimization, there are two parameters for recurring payments.

Additional required request parameters and optional request parameters for recurPayment.

Additionaly if you’re using the QENTA Fraud Prevention & Fraud Detection the data on the consumer can be submitted for processing.

Source Orders Based on SEPA Direct Debit

For recurring transactions based on SEPA Direct Debit, a given authorization by the consumer is used for regular direct debits initiated by the creditor, e.g payment for monthly rent. The initial mandateId signed by the consumer is used as a basis for all recurring transactions.

Table 1. For All Acquirers
Parameter Data type Description

mandateId

Alphanumeric, up to 35 characters.

Identifier of mandate.

mandateSignatureDate

Date as DD.MM.YYYY

Date when mandate was signed by the consumer.

transactionIdentifier

Enumeration

SINGLE, RECUR or INITIAL.

Table 2. For Acquirer b4payment Over Computop
Parameter Data type Description

consumerMerchantCrmId

Alphanumeric

Identifier of Merchant CRM.

Table 3. PayPal
Parameter Data type Description

transactionIdentifier

Enumeration

SINGLE, RECUR or INITIAL.

SEPA Direct Debit for Sofort Source Orders

Recurring transactions for Computop don’t require the parameter useIbanBic.

In order to process a SEPA recurring payment with Computop integration the mandatory parameter consumerMerchantCrmId needs to be added.

Recurring transactions for Hobex don’t require the parameters useIbanBic and the parameter transactionIdentifier.

It’s not possible to extend an authorization, so you can use recurring payment which returns a new orderId and you need to cancel the original authorization as soon as possible. Anyhow if the transaction(s) exceed the limit, they will be declined by the issuing bank.

You’re able to do a recurring payment on an existing order which is not older than 400 days and to use expired or reversed orders as source orders within a time frame of 400 days.

refund

refund creates a credit note for the specified order and it can only be done after the order has been debited and the corresponding day-end closing has been done.

Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber,amount,currency

If supported by the financial service provider it’s possible to refund only a part of the deposited amount. You need to send additional information about the item you’ll refund or the items which will remain with your consumer. Use the additional operation request parameters for the shopping basket.

Parameters

For refunds there are additional optional request parameters available. An additional reference for each operation can therefore be set with the parameter merchantReference. For some payment methods information about the basket items on each refund is required, especially if only a part of the order is refunded. For this purpose the following shopping basket and merchantReference are available.

Although the following parameters are in general optional, either all parameters need to be set or none, except for basketItem(n)Description and basketItem(n)ImageUrl which remain optional.

A refund can only be done for an order for which the deposit has already been done and it’s not possible to do one refund for several orders, so you have to do a refund for each order.

refundReversal

refundReversal cancels a credit note and can only be done before the corresponding day-end closing has been executed.

Required order of the parameter values when computing the fingerprint
QPAY Checkout Page: customerId, shopId, toolkitPassword, secret, command, language,orderNumber,creditNumber

Additional required request parameters for refundReversal.

transferFund

transferFund creates a credit note without dependancy on a specific order. Depending on the relevant payment method, QENTA currently supports:

EXISTINGORDER

The parameters sourceOrderNumber and fundTransferType EXISTINGORDER are relevant to be used for this transfer type. The data of an existing order that are stored on QENTA Checkout Server are used.

The fund transfer type is used for the SEPA Direct Debit and Sofort.

Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber,creditNumber,orderDescription,amount,currency,orderReference,customerStatement,fundTransferType,sourceOrderNumber

SEPA-CT

SEPA-CT is used to pay out money to any bank account using SEPA standard. Thus, the parameters bankBic, bankAccountIban, bankAccountOwner and fundTransferType are relevant to be used.

SEPA-CT is used for all payment methods provided that the BIC, IBAN and account owner are known.
Required order of the parameter values when computing the fingerprint
customerId,shopId,toolkitPassword,secret,command,language,orderNumber,creditNumber,orderDescription,amount,currency,orderReference,customerStatement,fundTransferType,bankAccountOwner,bankBic,bankAccountIban

Additional required request parameters and response parameters for refundReversal.