At the core of our payment processing platform is the Judopay API. You can use the API to process multiple payment functions and configure a checkout to suit your business needs.
Interact with Judopay using our Native SDKs for payments within a native app or Web payments within a mobile website or web app.
This overview covers the different payment functions that Judopay offers. If you already know what you’re after and are ready to dive in, you can select your integration method and access SDK guides via the Judopay Docs homepage or see our complete API reference.
Register a card
Card registration will tokenize a card into an encrypted string to process future payments.
The ‘Register card’ method conducts a pre-authorization configured to reserve a specific amount in the customer’s bank account. The pre-authorization can then be voided in order to not appear in the customer’s bank statement.
A card payment covers the vast majority of retail transactions, such as in-store payments, settling a bill at a restaurant, or ordering goods remotely for delivery.
A card payment has the most in common with traditional cash payments, with your customer’s card charged at the point of sale.
To process a card payment, your customer will be required to provide their full card details (16-digit card number, expiry date and CV2).
Card payments can be implemented for a multitude of different business scenarios, some of which are:
- Paying in-store for immediate delivery of goods.
- Purchasing a top-up for a loyalty-card scheme.
- Paying for a service to be provided at an agreed-upon date.
- Ordering goods remotely for delivery or collection.
Repeat card payments
Once your customer has processed their first successful payment, there’s no reason they should have to enter their details again when making subsequent payments to your business. Instead you can reduce the amount of data entry for returning customers by storing their data to process future payments.
After a payment has been processed successfully, Judopay provides you with a card token and a consumer token. These tokens can be stored and used with the original Consumer Reference to process future payments on behalf of that customer. This means that by processing a token payment, returning customers will only need to enter their CV2 to complete the transaction.
We also offer one-click payments, whereby your customer will not be required to enter any card details for repeat payments. This situation is very useful, for example, when you want to set up recurring payments for subscriptions or top-ups on behalf of the customer. This is a custom feature, so if it’s one of your requirements please let us know.
Storing raw card data – i.e. the actual numbers on the card – involves rigorous and complex legal requirements. Tokenized data is inherently less sensitive than raw data, but still needs to be stored securely. If you’re looking to store card tokens, see the Secure your mobile apps section to learn more.
Note: When performing a token payment, the Consumer reference has to be the same used when the card token was originally created. See our API reference for more information.
Reserve and collect funds
A business may choose to reserve (pre-authorize) funds on a card and postpone completing the payment until the goods have been delivered, or the service has been fulfilled.
PreAuth and Collection
For example, a taxi app might reserve funds at the start of a journey and collect them only after the journey is complete. You can use a pre-authorization to perform this ‘reserve and collection’ of funds.
For your customer at the checkout, there is no difference or extra work required to process a payment of this kind – it’s all carried out in the back-end. However, you can choose to let your customer know when they can expect their card to be charged with a simple message, such as: ‘You have not yet been charged for this item. We won’t debit any funds from your payment card until your journey is complete.’
Is this scenario, when the taxi arrives at its destination, you can update your system to send a request to collect the funds you’ve previously reserved.
PreAuth and Void
PreAuths can also be beneficial if the customer’s purchase is at all contingent upon variables beyond your business’s control, such as availability of raw materials. With a pre-authorization you do not actually charge the card, which means you do not have to worry about processing a refund if the details of the order change.
If your business is not going to charge the customer, you will be able to void the pre-authorization.
Note: If a pre-authorization is not collected, it will expire within the next three days, releasing the reserved funds for that particular transaction.
If the details of one of your sales change, you might need to process a refund to return those funds to the customer.
Depending on the specifics of your situation, you may need to process a full or a partial refund.
A full refund returns the total of the original transaction back to the card holder. This is often employed in instances where the original agreement between buyer and seller has been rendered void and so no charges can be justifiably applied.
A partial refund returns a specified amount of the original transaction back to the customer. This can be used in scenarios where a customer has been overcharged or where part of an order can’t be satisfied by the business.
If a transaction has been authorized by the card-holder bank, but the funds have yet to be settled, the merchant has the ability to cancel the transaction by voiding it.
Once a pre-authorization is voided, the transaction will be cancelled and no funds will be transferred from the customer’s account to the merchant’s. The pre-authorization will no longer appear in the customer’s bank statement if this functionality is supported by the issuing bank (the customer’s bank).
This option is particularly useful when you have performed a pre-authorization of an incorrect amount (e.g. by accidentally adding more products or services than the customer actually requested), and you want to void this particular transaction.
You can also use a void when your intention is to obtain a card token by performing a pre-authorization, but you don’t want to incur actual charges against the cardholder’s account. We recommend to perform a card registration for obtaining tokens.
Learn how to void a transaction by consulting our API reference.
Note: Not all the banks support voiding transactions.
Address Verification System (AVS) is another fraud prevention scheme. It uses information provided by your customer to verify the details of the card used in the transaction. It is used to help verify details in cardholder not present transactions, such as online and mobile.
AVS performs a cross-reference check between the billing address of the payment card and the billing address provided by the customer. If the check is successful then the transaction will be processed, otherwise the charge will not be authorized.
AVS performs the cross-reference check using the numerical values contained in the address information.
3D Secure (3 Domain Secure) is an authentication service for card payments that acts as an additional fraud prevention layer. It aims to confirm the consumer’s identity before processing an online purchase acting in a similar way to ‘Chip and PIN.’
3DS is also known as Verified by Visa (VBV) and MasterCard Secure Code (MSC). Typical implementations of 3DS allow customers to create a password that is associated with their card.
A transaction using VBV or MSC redirects the customer to the authorization website of the card’s issuing bank. On this website, the customer is expected to provide the requested characters from their password in order to authorize the payment. Since the password is not stored on the card it reduces the risk of card fraud owing to a stolen card or card details.