Riverty

1. Overview

The call-response sequence generally follows the card payment flow as described in the Payment Flow - Outline section. But there are a few additional parameters required for Riverty.

Since the customers payment method is submitted to a third party, you can identify what payment method has been used by sending the Query call after the Terminal phase.

2. Functionalities

3. User Journey

When your customers choose Riverty as a payment method, they are directed to the Netaxept payment window. Here, the customer is guided through the payment process and will then be redirected to the redirectURL as specified in the Register call. The Riverty service provider then sends an invoice to the customer and settles the payment to you within the agreed time.

4. Required Register call parameters

When using Riverty as a payment method, in addition to the Register call parameters as described before, more parameters become required.

numberOfGoods

The Register Call's numberOfGoods parameter is mandatory and it's value determines how many different items are invoiced.

https://test.epayment.nets.eu/Netaxept/Register.aspx?
  merchantId=xxxxxxxx&
  token=xxxxxxxx&
  ordernumber=order852&

In the example above, the Number of Goods is 2, indicating two items. The following parameters (amount_1, title_1, quantity_1, articleNumber_1, VAT_1, IsVatIncluded_1) refer to the first item.

The parameters are then repeated for the second item: amount_2, title_2 and so on.

This can be repeated, but the number of items (n) must be defined in the numberOfGoods parameter: numberOfGoods=n.

Please note, that for each item amount, title, quantity and articleNumber are mandatory parameters.

Learn more about aditional parameters in the API reference.

Customer information

For Riverty, to send customer information becomes mandatory. You can either pass on this information with the Register call, or collect the data on the Netaxept hosted payment window, if it is part of your implementation for the invoice payment flow.

In addition to

• customer's country (customerCountry)
• name (customerFirstName, customerLastName)
• address (customerAddress1)
• post code (customerPostcode)
• town (customerTown)

as shown in the example above, parameters such as

• email address (customerEmail)
• phone number (customerPhoneNumber) and
• social security number (customerSocialSecurityNumber)

are required as well for most providers.

5. Strong customer authentication (SCA)

For Riverty, no separate parameter needs to be send with the the Register call. Riverty – Riverty will route the transaction to SCA, based on the logic and rules on their side.

6. Partial credits and capture

Partial credit

To initiate a partial credit of an invoice, you need to send the relevant part of the transaction with the Process(Credit) call to Netaxept.

The numberOfGoods parameter needs to be adjusted to the number of goods that are subject to the credit operation. The values of the related parameters (amount_1, title_1, quantity_1 and so on) must refer to the items you want to refund.

Apart from quantity_1, the parameter's values need to be consistent with the parameters for the same item in the original invoice: i.e. if an item in the initial invoice had VAT_1= 24%, then the same item and VAT percentage must be repeated in the Process(Credit) call.

https://test.epayment.nets.eu/Netaxept/Process.aspx?
	merchantId=MERCHANTID&
	token=TESTTOKEN& 
	transactionId=TRANSACTIONID&

The example above builds on the example given for invoices earlier:

Let's assume you want to refund the payment for just 100 out of the 200 pencils that have been ordered and invoiced.

Here the amount is the amount you want to return: 5000 EUR (100 pencils for 50 EUR each). The numberOfGoods parameter has been changed to 1, since only pencils and no additional items have been returned. The quantity_1 has also changed to 100 (the amount of pencils you want to refund). amount_1 (the price for each pencil) remains the same as in the initial invoice: 50 EUR.

Partial capture

When running partial capture, the Process(CAPTURE) call must contain the numberOfGoods parameter. The corresponding parameter for the item for which you want to capture the funds must be added, similiar to Process(CREDIT) call as shown before.

As an immediate response to your Process(CAPTURE) (or Process(SALE)) call, you'll get the SubTransactionId. You can also fetch it later, using the Query call.

7. Recurring billing

Initial transaction

These Register call parameters become required, for the intitial transaction of a recurring billing:

• recurringType=S
• paymentMethodActionList: Riverty must be included

Apart from that, the flow is similiar to the standart payment flow: you send the Terminal call to direct the customer to the payment window.

Get the panHash token

After you have sent the Process(CAPTURE) call, you send the Query call to get the panHash token. Store this token on your database's customer profile.

Subsequent transactions

The Register call's parameter for subsequent transactions need to be as follows:

• panHash: the stored panHash token from the initial transaction
• recurringType=S
• serviceType=S
• paymentMethodActionList: Riverty must be included

As usually, the flow ends with you sending the Process(Capture) call.