Payment authorization refers to the process of verifying the validity and availability of funds for a payment transaction. It typically occurs before the actual fund's transfer takes place.
In various payment scenarios like e-commerce, authorisation is initiated through an API call to the payment gateway. The gateway and payment processor conduct necessary validations and risk assessments, and request approval from the card network to transfer funds from the issuer to the acquirer.
If a payment has been authorized but not yet captured, a merchant has the option to cancel it due to a high risk of fraud.
It's important to note that authorisation and capture are separate steps, In some cases, particularly for card-based transactions, authorisation and capture may happen almost simultaneously, making the process appear seamless to the customer. If an authorised payment is not captured or cancelled within the specified timeframe, it will expire.
To complete a payment that has been authorised, it needs to be captured, which involves transferring the reserved funds from the shopper to the merchant. The payment gateway offers the flexibility of separate authorisation and capture. This allows you to configure a delay before capturing funds, manually capture payments using both the Customer Area and API calls, conduct partial captures for specific amounts, or cancel an authorisation if needed.
Once a payment has been authorised, merchants have the option to either capture the funds and transfer them to their account or cancel/Void the payment if they have valid reasons, such as a high risk of fraud.
It's important to note that cancelling/Voiding a payment is only applicable before it has been captured. Once the funds have been transferred, if a cancellation is required, the merchant should initiate a refund to return the funds to the shopper.
The security code is a numeric code consisting of 3 or 4 digits, printed on a card alongside the card number. It serves as an additional layer of verification in card-not-present transactions, helping to confirm the identity of the cardholder.
The specific name of this code may vary depending on the card network:
Visa: Card Verification Value (CVV, CVV2)
MADA: Card verification value card security code (CVV,CSC).
Mastercard: Card Validation Code (CVC, CVC2)
American Express: Unique Card Code (CID)
The security code falls under the category of Sensitive Authentication Data, and therefore, it is subject to compliance restrictions outlined by the Payment Card Industry Data Security Standard (PCI DSS)
If a shopper wishes to have the funds returned by a merchant, they can request a refund directly from the merchant. In the event that the merchant declines the refund, the shopper has the option to initiate a chargeback through their card issuer, which involves reversing the funds from the merchant back to the shopper.
Once a chargeback is initiated, the merchant may have the opportunity to dispute it under certain circumstances. If the dispute process is available, the merchant must submit all required documentation to the payment processor for review.
In the context of payments, this refers to an unauthorized transaction attempted by a criminal. Both merchants and shoppers can be targets of fraudulent activities, depending on the tactics employed by the fraudster.
Effective fraud defense plays a crucial role in the payment process, and it is a service that can be offered by payment providers. Geidea, for example, provides such a service through notolytix, which helps safeguard against fraudulent transactions.
A Mail Order/Telephone Order (MOTO) transaction refers to a card-not-present payment where the shopper/Customer provides payment details to the merchant through mail (not email), fax, or telephone.
MOTO transactions commonly take place offline, meaning that instead of entering payment information on an online form, shoppers interact with a call center or send a coupon/voucher containing their credit card number.
By leveraging the MOTO features provided by Geidea, you can seamlessly integrate payments from your webshop and call center, benefiting from consolidated reporting that encompasses both transaction flows. This integration allows for streamlined management and analysis of your payment activities across various channels.
The Merchant Category Code (MCC) is a four-digit code utilized by card networks to classify a merchant's business based on the nature of the goods or services they provide. It is alternatively known as the Card Acceptor Business Code. During the onboarding process, the acquirer typically assigns an MCC to each merchant and associates it with all payment transactions.
Maintaining PCI DSS compliance entails consistently meeting all relevant requirements outlined in the current Payment Card Industry Data Security Standard (PCI DSS). The PCI DSS was established by major card networks to enhance the security of cardholder data and mitigate the risk of fraud. Any organization involved in payment card processing is obligated to achieve PCI compliance, which involves adhering to rigorous measures for safeguarding cardholder data.
Merchants who encounter challenges or cost barriers in fully achieving PCI DSS compliance have the option to explore alternative approaches. They may opt to utilize encrypted methods, such as Hosting the Cardholder Data Environment (CSE) library, or choose to outsource their card processing operations to a PCI-compliant payment service provider like Geidea. These alternatives can significantly reduce the scope of PCI DSS compliance requirements for the merchants while ensuring the secure handling of cardholder data.
As a PCI-compliant payment processor, Geidea offers the capability to securely store payment details, facilitating recurring payments for merchants. To enable this feature, merchants need to activate the recurring contract during the initial authorisation call made to the Geidea payments platform. In return, they receive a token that is uniquely associated with a specific shopper/Customer and their payment data.
Once recurring payments are enabled, merchants can utilize this token for future transactions. When charging a shopper for a subscription, initiating a card-on-file payment, or initiating an unscheduled card-on-file payment, the merchant includes the token in the authorisation call.
Tokenization involves the substitution of sensitive data with non-sensitive data, known as a token. In the context of the payments industry, tokenization is utilized to enhance security by replacing a card number and other payment data with a distinct string of numbers. This token can be utilized later to facilitate recurring payments.
By leveraging tokenization alongside Client-Side Encryption, merchants can securely transmit their customers' data to a payment service provider such as Geidea. This combined approach ensures the protection of sensitive information throughout the payment process, providing an added layer of security and peace of mind.
Updated 9 months ago