Credit card operations - card not present

Sale

The Sale transaction is the most basic and most common transaction, used for the sale/purchase of goods or services. This type of transaction compares the cardholder’s credit limit to the amount specified in the transaction. If the amount specified is available, the transaction is approved by the card issuer and an approval code is returned. If the amount is not available, or the transaction is denied for any other reason by the issuer, an error message containing the reason is returned.

Sale operation types

Jupiter lets you widely customize your sale information and take control of your business fees. Below, you will find detailed information about requests supported.

Associate to customer

In this situation, you would like to associate the sale to a specific customer previously registered. Required additional fields are description and the customerId.

Dynamic Fee

Dynamic fee lets you decide how much to charge for each transaction to your customers. Required additional fields is an object dynamicFee with properties fixed and discountRatePerc.

API Reference Sale | Sale Interactive Demo

Authorization

An Authorization transaction is used to verify funds when the total amount of the purchase is unknown. For example, restaurants use Authorization Completions to enter in the final total amount after a customer has added a tip and signed the receipt. Authorization is 2-step process. First, you make a request for authorizing some amount and then complete the operation in a Capture request.

API Reference Authorization | Authorization Interactive Demo

Capture

A Capture request is used to collect the final amount of a previously successful Authorization request. A Capture request can be entered for any amount up to an allowable excess limit. The allowable excess limit is determined by the card association. If the final amount exceeds the Authorization allowable excess limit, then the merchant should proceed with a Sale operation. Remember you need to make an Authorization request first in order to make a capture request. If an Authorization is not made, the capture will fail

API Reference Capture | Capture Interactive Demo

AVS

The Address Verification Service (AVS) Only transaction may be used by submerchants to determine whether to accept a transaction. This type of transaction only returns AVS information and does not request authorization. The format of the AVS information is exactly the same as the format used for Sale transactions.

API Reference AVS

Void

A Void transaction can be used to back out a previous transaction. This applies to all transactions that were entered into the current batch, and only for the full dollar amount of the original transaction.

API Reference Void | Void Interactive Demo

Refund

A Refund transaction requires a TransactionID from the original dependent transaction. (For example: A customer returns merchandise and wants a refund. A Credit transaction is used to refund a cardholder for a previous transaction.

API Reference Refund | Refund Interactive Demo

Rollback

The rollback (or communications/System Reversal) is generated when there is a problem delivering the response back to the server side code. It is the transaction requestor’s responsibility to generate a rollback transaction for all transactions that do not receive responses.

API Reference Rollback