Process payments - Outline
This guide is for developers, who want to programatically perform operations on card payments.
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): Independently of an actual purchase, you might want to only check whether a card is valid, for instance to store it for recurring payments.
- Process(QUERY): This call is relevant, when you offer additional payment methods that are not card payments. Since different payment methods determine how to process these payments and what calls you can use, you might need to check the actual payment method used by the customer.
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
operation(auth), Transaction ID
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
ExecutionTime and the
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.
It is compliant with Visa and Mastercard and it will have no effect on the cards balance.
The main use case for the Process(VERIFY) call is to check, if a card you want to store for future, recurring payments (create token), is valid, without doing 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.
Pre-authorization enables you to adjust the authorized amount before capture. After a payment is initiated, it allows you to increase or decrease the final amount to be captured during the payment process.
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 DK acquiring only. See Availability for more information.