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
Additional required request parameters for approveReversal.
| 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 |
|---|---|---|
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 |
|---|---|
|
Credit Card, Maestro SecureCode |
|
Credit Card MOTO |
|
Circle K |
|
CVC |
|
Dollar General |
|
EPS-Überweisung |
|
Hobex SEPA |
|
Ideal |
|
Invoice by Payolution |
|
Mastercard Maestro |
|
oBucks |
|
PayPal |
|
PagoEfectivo |
|
Paysafecard |
|
Przelewy24 |
|
Riverty |
|
Klarna Sofort |
|
Direct Debit |
|
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. |
|
(15/30761)-No payer assigned to EC token. |
|
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. |
|
WCP: Auth: Verification failed. |
|
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.
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.
| Parameter | Data type | Description |
|---|---|---|
Alphanumeric, up to 35 characters. |
Identifier of mandate. |
|
Date as |
Date when mandate was signed by the consumer. |
|
Enumeration |
|
| Parameter | Data type | Description |
|---|---|---|
|
Alphanumeric |
Identifier of Merchant CRM. |
| Parameter | Data type | Description |
|---|---|---|
Enumeration |
|
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.
Response backend operations parameters and source orders based on SEPA Direct Debit for recurPayment.
Response backend operations parameters and source orders based on SEPA Direct Debit for recurPayment.
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.
Additional required request parameters and response request parameters for refund.
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:
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.
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.