Process payments - Outline
This guide is for developers, who want to programatically perform operations on card payments.
Overview
The following examples refer to the test environment. For production you need to use your Netaxept API token and the production environment url instead.
test environment url: https://test.epayment.nets.eu/netaxept/
production environment url: https://epayment.nets.eu/netaxept/
The operations you can perform on card payments might depend on the specific card used. In general, the operations to be executed depend on decisions made as shown below:
All financial operations are encapsulated by the Process call and must for most payment methods be done within 24 hours of the customer being redirected back from the Payment Window.
The following two calls are used to process card payments:
- Process(AUTH): as a result, the payment is reserved, ready for you to capture once the item has been sent
- Process(CAPTURE): once you’ve sent the item, you can capture the payment to have it transferred to your account
If, for example for digital goods, the purchased items are sent immediately, then you don't need to separate capture from the authorization, and:
- Process(SALE) can be used. It is an alternative that allows you to authorize and Capture with a single call.
There are two ways for you, to cancel a payment:
- Process(ANNUL): this needs to be send after Process(AUTH) and before Process(CAPTURE). Technically speaking, the granted Authorization on the reserved amount gets canceled – without having moved the funds at all.
- Process(CREDIT): in case an item is returned to you, and you already captured the payment with Process(CAPTURE) you need to refund the payment with Process(CREDIT)
Additional use cases:
-
Process(VERIFY): You may want to check the card's validity independently of an actual purchase. For example, to store it for recurring payments.
-
Query: With this call, you can retrieve transaction data. It is essential for understanding the payment method used in your transactions and is vital for scenarios such as identifying payment methods, error handling, confirming payment success, and managing tokens. You can perform the Query after any operation, such as Register, Terminal phase and Process. For more detailed information about the Query call, please refer to our dedicated Query call page.
Process the payment with Process(AUTH)
For card payments it is possible, to reserve the amount previously set in the Register call, before performing the actual charge. That allows you to make sure the ordered item has been sent, before charging the customer’s card. It is also possible, to do a partial charge, after the authorization. This helps to avoid chargebacks.
To authorize the transaction, you need to send the Process(Auth) call with the following required parameters: Merchant ID merchantId, Token token, Operation operation(auth), Transaction ID transactionId.
Here is an example of a possible Process(AUTH) call.
Example Process(AUTH) call - line breaks added for readability
https://test.epayment.nets.eu/Netaxept/Process.aspx? merchantId=MERCHANTID& token=TESTAPITOKEN& operation=AUTH&
The response to that call need to contain status=OK in order to proceed. In any case, the response's status allows you to take further action, such as sending a "Thank you" message or an error message to the customer.
These parameters are sufficient for the Process(AUTH) call to work. If successful, the Process(AUTH) response will contain the Operation, the transactionId, the AuthorizationId, the ExecutionTime and the BatchNumber.
Separate capture (separation between authorization and capture) is not available for all transactions. Please check our payment methods section for more details.
Capture the payment - Process(CAPTURE)
By now you have only (reserved) the funds. After you have sent the goods to the customer, it is time to capture the amount with the Process (Capture) call. If necessary, you may capture only a part of the authorized amount.
If you are unable to ship all items of the order, you can add isFinalCapture=true parameter to the final partial Capture request, which indicates that it is the last Capture and then releases the remaining authorization.
If you want to do multiple partial captures, you need to set isFinalCapture=false for the partial captures before the final one. Read more about isFinalCapture in the API reference.
Process (Capture) example - line breaks just for readability
https://test.epayment.nets.eu/Netaxept/Process.aspx? merchantId=MERCHANTID& token=TESTTOKEN& transactionId=TRANSACTIONID&
The capture needs to be done while the authorization is still valid, if applicable. Many card issuers are using a time limit for that. Beyond this, the response depends on the card issuer and the specific account. The credit is available for 365 days.
Cancel the payment - Process(ANNUL) - optional
There are multiple reasons that might force you to cancel a payment: the customer might have revoked the purchase, or you might have run out of the item that has been ordered.
As long as you have authorized (Process(AUTH)) the amount, but not yet captured it (Process(CAPTURE)) you can cancel the payment (Process(ANNUL)).
As always, the required parameters for that call include the merchantId and the transactionId, while the operation parameter has to be set to ANNUL.
Example Process(ANNUL) call - line breaks added for readability
https://test.epayment.nets.eu/Netaxept/Process.aspx? merchantId=MERCHANTID& token=TESTAPITOKEN& operation=ANNUL&
If you have already performed the Process(CAPTURE) call or the Process(SALE) call, the amount has already been captured from the customer. In that case, you can not use Process(ANNUL) but need to send the Process(Credit) call instead.
Refund a payment - Process(CREDIT) - optional
If the customer returns the product or the purchase is cancelled for any other reason, and you have already captured the payment, you need to credit a previously captured amount by performing the Process (Credit) call. During the credit, the captured amount is returned to the customer's account. If necessary, you can credit only a part of the captured amount.
Verify card - Process(VERIFY) - optional
If you want to ensure that the card used in the purchase is currently valid and active, you can perform account verification by using the Process(Verify) call, also known as the Zero-amount authorization.
It is compliant with Visa, Mastercard, American Express, Dankort and Diners Club, and it will have no effect on the card's balance.
The primary use case for the Process(VERIFY) call is to check if a card is valid for future recurring payments (to create a token), without conducting an actual charge.
Example Process(VERIFY) call - line breaks added for readability
https://test.epayment.nets.eu/Netaxept/Process.aspx? merchantId=MERCHANTID& token=TESTAPITOKEN& operation=VERIFY&
Pre-authorization and authorization adjustments
When it is required to adjust the authorized amount before the capture, it can be done by implementing pre-authorization. In pre-authorization payment flow you can increase or decrease the authorized amount if you do not know the final amount to be captured when the transaction begins.
Authorization types for order adjustments:
- Pre-authorization is intended for use cases where the final amount to be captured is not yet known, and you may need to increase or decrease the amount at a later stage.
- Incremental authorization allows you to increase the total authorized amount before you capture it if the authorized amount appears to be insufficient. This is helpful in situations where the total price of goods or services changes. Multiple incremental authorizations can be performed throughout the duration of the transaction.
- Reversal authorization is used to partially reverse the authorization if the final capture amount is less than the estimated authorized amount.
Pre-authorization, incremental and reversal authorizations are currently available only for Visa and Mastercard and through Nets Nordic acquiring only. See Availability for more information.