description |
---|
Understand the flow of a transaction through Hyperswitch |
{% hint style="info" %} This chapter will cover the payment flows available with Hyperswitch. Please reach out to us to learn more about the payment flows supported! {% endhint %}
There are multiple stages in a Payment flow depending on the payment methods that are involved. Considering an one-time payment method where there was no redirection involved, the following stages form the Payment flow:
a) Creating a Payment: When your customer wants to checkout, create a payment by hitting the payments/create endpoint. Fetch and store the payment_id and client_secret
b) Loading the SDK: After your customer checks out, load the Hyperswitch SDK by initiating it with the client_secret and publishable_key
c) SDK being rendered: After you initiate the SDK, the SDK makes several API calls involving the /sessions and /payment_methods endpoints to load relevant payment methods and any saved cards associated with the customer
d) Customer enters the payment method data: After the SDK is fully rendered, your customer would choose a payment method and enter the relevant information and click pay
e) Confirming the payment: After the customer clicks pay, the SDK calls the payments/confirm endpoint with the customer's payment method details and post response, it displays the payment status
Here's a more detailed version of the payment flow:
Customer Action | Direct/Redirect flows | Payment- finalized immediately | Payment- finalized later |
---|---|---|---|
Customer action required before payments/ confirm | Within Hyperswitch SDK |
|
|
Customer action required before payments/ confirm | 3rd party Redirect/SDK |
| |
Customer action required after payments/ confirm | 3rd party Redirect |
|
|
Accept online payments | Get started with accepting one time payments globally on your online store | onlinePayments.jpg | quickstart | |
Setup mandates & recurring payments | Setup payments for a future date or charge your customers on a recurring basis | recurringPayments.jpg | mandates-and-recurring-payments.md | |
Manage payouts | Facilitate payouts for global network of partners and service providers | Payment flow (1) (1).jpg | payouts | |
Save a card during payment | Learn how you can save your customers' cards in a secure PCI compliant manner | saveCard.jpg | tokenization-and-saved-cards.md | |
Manage payments on your platform / marketplace | Accept payments from your customers and process payouts to the sellers on your marketplace | marketplace.jpg | multiple-accounts-and-profiles.md | |
Accept payments on your e-commerce platform | Give your Wordpress store a lightweight and embedded payment experience with the Hyperswitch WooCommerce plugin | WooComerce.jpg | woocommerce-plugin | |
Create payment links | Accept payments for your products through reusable links without writing any code | paymentLinks.jpg | payment-links.md |
Hyperswitch uses the PaymentIntent
object to track the status of a payment initiated by you. Since, Hyperswitch enables retrying a single payment multiple times across different processors until a successful transaction, we track each of these payment attempts through separate PaymentAttempt
objects.
While PaymentIntent
and PaymentAttempt
have their own state machines, the various states in PaymentAttempt
are also constrained by their respective mapping to the PaymentIntent
statuses.
PaymentIntent state machine:
The following is an abridged version of the PaymentIntent
state machine flow that covers majority of the above payment use-cases.
%%{
init: {
'theme': 'forest',
'themeVariables': {
'fontSize': '14px',
'background': '#17202A'
}
}
}%%
flowchart TD
A{PaymentsAPI} --> |amount,currency|RequiresPaymentMethod
RequiresPaymentMethod -->|payment_method| RequiresConfirmation
RequiresConfirmation --> |confirm| Processing
Processing --> AuthType{auth type\nselection}
AuthType --> |3ds| RequiresCustomerAction
AuthType --> |no-3ds| CaptureMethod{capture method\nselection}
CaptureMethod --> |manual| RequiresCapture
CaptureMethod --> |automatic| Succeeded
RequiresCustomerAction --> CustomerAction{customer_action\nresult}
CustomerAction -->|success| CaptureMethod
CustomerAction -->|failure| Failed
RequiresCapture --> |capture|Succeeded
PaymentAttempt state machine:
The following is an abridged version of the PaymentAttempt
state machine flow that covers majority of the above payment use-cases.
%%{
init: {
'theme': 'forest',
'themeVariables': {
'fontSize': '16px',
'background': '#17202A'
}
}
}%%
flowchart TD
AuthenticationFailed
AuthenticationPending
AuthenticationSuccessful
Authorized
AuthorizationFailed
Charged
Voided
CaptureInitiated
CaptureFailed
Pending
PaymentMethodAwaited
ConfirmationAwaited
DeviceDataCollectionPending
A{PaymentsAPI} --> |amount,currency|PaymentMethodAwaited
PaymentMethodAwaited -->|payment_method| ConfirmationAwaited
ConfirmationAwaited --> |confirm| Pending
%% Before calling the connector change status to Pending
Pending --> CallConnector{CallConnector}
CallConnector -->|Success| AuthType{auth_type}
CallConnector -->|Fail| AuthorizationFailed
AuthType --> |no-3ds| CaptureMethod{capture_method}
AuthType --> |3ds| DeviceDataCollectionPending
DeviceDataCollectionPending --> |CollectDeviceData|AuthenticationPending --> Authenticate{Authenticate}
Authenticate --> |Success| AuthenticationSuccessful --> CaptureMethod{capture method}
Authenticate --> |Failure| AuthenticationFailed
%% Capture
CaptureMethod --> |automatic| Charged
CaptureMethod --> |manual| Authorized
Authorized --> |capture| CaptureInitiated --> Capture{Capture at connector}
Capture -->|Success| Charged
Capture -->|Failed| CaptureFailed
%% Payment can be voided after calling the connector but not charged
%% This will not void the payment at connector
DeviceDataCollectionPending -->|void| Voided
AuthenticationPending -->|void| Voided
%% Voiding a payment after it is Authorized will void at connector
Authorized -->|void|Voided