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

Parameters

No additional response parameters are returned.

deposit

deposit is executed by the merchant 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.

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.

Required order of the parameter values when computing the fingerprint

customerId,shopId,toolkitPassword,secret,command,language,orderNumber,amount,currency

Parameters

Shopping basket parameters must be sent for a split capture for Riverty and Payolution.

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

Parameters

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

Parameters

Additional required request parameters for getOrderDetails.

Within the additional response parameters, some parameters 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

The 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.

payment.{n}.{m}.instrumentCountry

Data

Value

Data type

Alphabetic, fixed 2.

Description

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

CCARD

Credit Card, Maestro SecureCode

CCARD-MOTO

Credit Card MOTO

CIRCLEK

Circle K

CVSPHARMACY

CVC

DOLLARGENERAL

Dollar General

EPS

EPS-Überweisung

ELV

Hobex SEPA

IDL

Ideal

INVOICE

Invoice by Payolution

MAESTRO

Mastercard Maestro

OPENBUCKSCARD

oBucks

PAYPAL

PayPal

PAGOEFECTIVO

PagoEfectivo

PSC

Paysafecard

PRZELEWY24

Przelewy24

AFTERPAY

Riverty

SOFORTUEBERWEISUNG

Klarna Sofort

SEPA-DD

Direct Debit

SAFETYPAY

Safetypay

Return Message

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 that have entered.

20003

WCP: Auth: Verification failed.

2

paySysMessage depends on the relevant financial service provider’s 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

Parameters

According to credit card company requirements for risk minimization, there are two parameters for recurring payments.

Additional required and optional request parameters for recurPayment.

Additional required and optional request parameters for recurPayment.

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. b4payment
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 b4payment don’t require the parameter useIbanBic.

To process a SEPA recurring payment with b4payment integration the mandatory parameter consumerMerchantCrmId needs to be added.

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

Extending an authorization is not possible, so recurring payment returns a new order Id and the original authorization should be canceled as soon as possible. Anyhow if the transaction(s) exceeds the limit, it will be declined by the issuing bank.

A recurring payment can be made for an existing order which is not older than 400 days and 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

Parameters

If supported by the financial service provider it’s possible to refund only a part of the deposited amount. Send additional optional request parameters for the shopping basket e.g. additional information about the item for a refund or the items which remain with the consumer should be sent.

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 a refund should be done 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

customerId,shopId,toolkitPassword,secret,command,language,orderNumber,creditNumber

Parameters

Additional required request parameters for refundReversal.

transferFund

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

EXISTINGORDER

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

Parameters

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.

SEPA-CT

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

Parameters

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.

Additional required request parameters and response parameters for refundReversal.