Transaction types
Types of transactions Carouseller processes
Transaction type table
1
Authorization
2
Authorization confirmation
3
Direct debit
4
Authorization decline
5
Refund
6
rebill
Recurrent payment
7
Chargeback
8
complete3ds
Complete the payment 3ds
11
Pay-out
12
readonlyinvoice
Read only invoice
13
Fraud
Authorisation
In the payment world, authorization refers to the process of obtaining approval or permission from the relevant parties to complete a transaction. It is a crucial step in ensuring that a payment can be processed and funds can be transferred from the customer's account to the merchant's account.
When a customer initiates a payment, such as making a purchase using a credit or debit card, the authorization process typically involves the following steps:
Request for Authorization: The merchant, through their payment processor or acquiring bank, sends a request for authorization to the customer's card issuer or bank. This request includes information such as the transaction amount, merchant details, and customer account information.
Card Issuer Verification: The customer's card issuer receives the authorization request and verifies the available balance or credit limit on the customer's card. They also check for any restrictions, such as blocked cards or suspicious activity, that may prevent authorization.
Authorization Response: The card issuer sends an authorization response back to the merchant or payment processor. This response indicates whether the transaction is approved or declined. It may also include additional information such as an authorization code.
Transaction Completion: If the authorization is approved, the merchant can proceed with completing the transaction. The customer's account will be debited, and the funds will be transferred to the merchant's account. If the authorization is declined, the transaction cannot be completed, and the customer will be notified of the decline.
It's important to note that an authorization is not the same as a payment settlement. Authorization merely confirms that the customer has sufficient funds or credit available at the time of the request. The actual transfer of funds and settlement occurs later during the payment settlement process.
Authorization helps protect both merchants and customers by ensuring that funds are available and transactions are legitimate before the goods or services are provided. It helps prevent unauthorized or fraudulent transactions and helps manage the risk associated with payments.
Authorisation confirmation
authorization confirmation refers to a notification or confirmation message sent to the merchant or the payment processor after the authorization process has been successfully completed. It serves as a proof that the transaction has been authorized and approved by the card issuer or the bank.
When a payment authorization request is sent by the merchant to the card issuer or bank, the authorization confirmation is the response received from the card issuer indicating that the transaction has been approved. This confirmation typically includes an authorization code, which is a unique identifier associated with the approved transaction.
The authorization confirmation provides assurance to the merchant that they can proceed with completing the transaction and delivering the goods or services to the customer. It also serves as a reference for future inquiries or disputes related to the transaction.
It's important for the merchant to retain the authorization confirmation, either electronically or in a physical form, as it may be required as evidence in case of any discrepancies or chargebacks that may arise later in the payment process.
It's worth noting that the authorization confirmation does not guarantee that the payment will be successfully settled or that the funds will be received by the merchant. The settlement process, which involves the actual transfer of funds, occurs separately and may have its own confirmation or notification.
Purchase
Algorithm
The User makes a purchase/deposit request for a Service
The Cashier has to receive a confirmation from the Service by sending the Users data
If the Service confirms the request, it sends a request with data and external ID to the cashier about the deposit request.
Cashier sends Users data to the Payment System
The Payment System sends out a payment request to the Acquiring Bank
Acquiring Bank sends request for payment from the Issuing Bank
Issuing Bank responds by sending funds to the Acquiring Bank
Acquiring Bank responds to the Payment System with the funds
The Payment System sends a response to the Cashier along side a callback containing transaction info and status
The Cashier sends a notification to the Service
The Service credits the User with the requested amount
In the payment world, a purchase refers to a transaction where a customer acquires goods, services, or other items in exchange for payment. It is a fundamental type of transaction that occurs between a buyer (customer) and a seller (merchant).
When a customer wishes to make a purchase, they typically initiate the process by selecting the desired item or service and expressing their intent to buy it. The actual purchase process can vary depending on the payment method used. Here are a few common scenarios:
Card-based Purchase: If the customer is using a credit or debit card, they may provide their card details to the merchant. The merchant then processes the payment by sending an authorization request to the card issuer or the payment network associated with the card. Upon receiving authorization approval, the merchant completes the purchase, and the customer's account is charged accordingly.
Online Purchase: In the case of online purchases, the customer usually adds items to a virtual shopping cart on a website or app. When they are ready to complete the purchase, they proceed to a checkout page where they provide their payment information. The payment is then processed through various online payment methods, such as credit/debit cards, digital wallets, or online payment gateways.
Regardless of the specific payment method, a purchase involves the transfer of value from the customer to the merchant in exchange for the goods, services, or items being acquired. The completion of a purchase often triggers subsequent processes, such as shipping, delivery, or the provision of the purchased goods or services to the customer.
Void
A void transaction refers to the cancellation or nullification of a payment transaction before it is fully processed and settled. When a transaction is voided, it is as if the transaction never took place, and it does not appear on the customer's statement or affect their account balance.
Typically, void transactions occur shortly after the initial transaction is authorized but before it is captured or settled. They are often used to correct errors, such as entering the wrong amount, selecting the wrong product or service, or processing a duplicate transaction.
Voiding a transaction is different from issuing a refund. A void transaction cancels the transaction before it is settled, while a refund occurs after the transaction has been settled, and the funds are returned to the customer.
It's important to note that the ability to void a transaction depends on the payment processor and the specific circumstances. Not all transactions may be eligible for voiding, especially if they have already been settled.
Withdrawal
Algorithm:
User requests to make a withdrawal in the Carouseller Cashier
The Cashier sends a request with the transaction data to the Carouseller Payment Approver
The Approver approves or declines the transaction
Approver sends a callback with the data and status of the transaction to the Cashier
The Cashier sends withdrawal request to the Carouseller Payment System
Payment System makes the withdrawal and sends back Cashier the data about transaction
The Cashier sends data about the transaction to the User
Request address:
Respond to the payout request:
Request parameters
site_id
Yes
integer
Site identifier in the system
3327
amount
Yes
integer
Amount to be paid in minor units, e.g. for USD - in cents.
100
currency
Yes
alpha-3 ISO 4217
Withdrawal currency
GBP
external_id
Yes
string(256)
Unique order identifier in the Merchant's system
AA00033
site_login
Yes
varchar(256)
User's site login
user_test
customer_ip
Yes
inet (ipv4 or ipv6) string
Ip for the authorization
8.8.8.8
display_payment_group_id
Yes
integer
Payment group, by which the User is going to withdraw funds
17
invoice_id
Yes
integer
Invoice ID in a cashier (in the request_payout)
3921556
user_preset_id
No
integer
Preset ID
101
comment
No
string(4096)
Comment to the request
example_comment
country_code
No
String(256)
User's country
GB
signature
Yes
SHA-1
Request signature, see Request signature generating rules
d9f5713990de5c6e32169dba1f0102f540018975
Request responses
0
Success - Withdrawal sent to the processing
100
Error, error description is in the processor_message field
401
Error, withdrawal with the same external_id already accepted to the processing or successfully completed
5001
Error, error description is in the processor_message field
Refund
How to process a refund
Refund transaction can be processed by API.
Refund can be full or partial.
To process full refund don't send a parameter amount. For partial - send amount.
Request address
Possible responds to the request:
Request parameters
Main parameters for the refund request processing
site_id
Yes
integer
Site identifier in the system
1
tr_id
Yes
varchar(256)
Transaction identifier
1414
signature
Yes
SHA-1
Respond signature, see Request signature generating rules
50a29ef99a552115c4d8c6502a56be75384d77ff
amount
No
float
Refund amount (for partial refund)
255.50
Respond parameters
code
Yes
Code
Find a description in the table below
status
Yes
Status
success or fail
msg
No
Error message
Refund not allowed
Possible options for respond codes (code)
100
Refund has been unsuccessful, error will be in msg
50
Refund was initiated, wait for callback
Payment groups which allow refunds
VISA
VISA Voucher
MasterCard
MasterCard Voucher
MIR
MIR Voucher
AMEX
Cabal
ELO
Hipercard
PIX
ApplePay
JCB
JCB Voucher
DinersClub
Discover
AlfaClick
CashU
QiWi
WebMoney
YooMoney
MTS
MegaFon
Tele2
PerfectMoney
NetBanking
UPI
RuPay
POLI
PayID
P2PSBP
PhonePe
IMPS
Wallet
GO
Neosurf
SberbankOnline
Trustly
Zimpler
Chargeback
To initiate a chargeback, certain conditions must generally be met, although the exact requirements may vary depending on the payment network, card issuer, and local regulations. Here are some common elements typically needed to make a chargeback:
Valid Reason: The cardholder must have a valid reason to dispute the transaction. This could include unauthorized charges, non-receipt of goods or services, defective products, billing errors, or dissatisfaction with the purchase.
Timely Request: Chargebacks usually have specific timeframes within which they must be requested. Cardholders are typically required to initiate the chargeback within a specified period from the transaction date or the statement billing date.
Attempted Resolution: The cardholder is typically expected to make a reasonable effort to resolve the issue directly with the merchant before initiating a chargeback. This can involve contacting customer support, requesting a refund, or attempting to resolve the dispute through other means.
Supporting Documentation: Cardholders may be asked to provide relevant documentation to support their claim, such as order confirmation, shipping/tracking information, correspondence with the merchant, or evidence of attempts to resolve the issue.
Procedural Compliance: Following the card issuer's procedures for initiating a chargeback is essential. This may involve completing a chargeback form or contacting the card issuer's customer service to initiate the process.
Retrieval request
When a cardholder or card issuer raises concerns or disputes a transaction, they may initiate a retrieval request to obtain additional details from the merchant. The request typically includes specific transaction-related information, such as the transaction amount, date, and other identifying details.
The retrieval request is typically sent through the card network (e.g., Visa, Mastercard, etc.) to the acquiring bank (merchant's bank) who then forwards it to the merchant. The merchant is required to respond to the retrieval request within a specific timeframe, providing any relevant documentation or information related to the transaction.
The retrieval request is an important step in the chargeback process, as the card issuer uses the information provided by the merchant to evaluate the validity of the disputed transaction and make a decision on whether to proceed with a chargeback or take other appropriate actions.
It is crucial for merchants to promptly respond to retrieval requests and provide accurate and thorough information to ensure a fair evaluation of the disputed transaction. Failure to respond or inadequate responses may result in the card issuer proceeding with the chargeback based on the available information.
Last updated
