# SDK Payment flows {% hint style="info" %} If you're complete beginner to Digital Payments, take a look at this [Payments 101 ](https://hyperswitch.io/blogs/payments-101-for-a-developer)blog to get familiar with terminologies. {% endhint %} ### **Payments flow** 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: {% @mermaid/diagram content="%%{init: { "theme": "base", "themeVariables": { "primaryColor": "#ffffff", "primaryBorderColor": "#2563EB", "lineColor": "#2563EB", "secondaryColor": "#EFF6FF", "tertiaryColor": "#DBEAFE", "fontFamily": "Inter, system-ui, sans-serif", "fontSize": "14px", "textColor": "#000000", ``` "actorBkg": "#346DDB", "actorBorder": "#999999", "actorTextColor": "#ffffff", "signalColor": "#000000", "signalTextColor": "#696969", "labelBoxBkgColor": "#346DDB", "labelBoxBorderColor": "#2563EB", "loopTextColor": "#000080" ``` } }}%% sequenceDiagram participant MS as Merchant Server participant MC as Merchant Client participant SDK as Hyperswitch SDK participant HS as Hyperswitch Server participant PS as Processor Server ``` MS->>HS: payments/create (amount, currency, api_key) HS-->>MS: payments/create response (payment_id, client_secret) MS->>MC: pass client_secret, publishable_key MC->>SDK: initiate SDK (client_secret, publishable_key) SDK->>HS: /payment_methods_list (client_secret) HS-->>SDK: /payment_methods_list response (eligible payment methods) Note over SDK: Display payment sheet with eligible methods Note over SDK: Customer selects desired payment method
(Say Card and Enters their Card Details) SDK->>HS: payments/confirm (client_secret, payment_method_data) HS->>PS: payments/confirm to processor (with merchant credentials) PS-->>HS: payments/confirm response (status) HS-->>SDK: payments/confirm response (status) SDK-->>MC: return to return_url with status" %} ``` ### **How does Payment flow vary across Payment methods?**
Customer ActionDirect/Redirect flowsPayment- finalized immediatelyPayment- finalized later
Customer action required before payments/ confirmWithin Hyperswitch SDK
  • Non 3DS Cards
  • Bank Debits like ACH Debit, BACS Debit, SEPA Debit
Customer action required before payments/ confirm3rd party Redirect/SDK
  • Wallets like Apple Pay, Google pay, Paypal, AliPay
  • BNPL like Klarna, Afterpay, Affirm

Customer action required after payments/ confirm3rd party Redirect
  • 3DS cards
  • Bank Redirects like iDeal, Giropay, eps
  • Bank Transfers like ACH Transfer, SEPA Transfer, BACS Transfer, Multibanco
  • Crypto wallets like Cryptopay
### **Functionalities provided by Hyperswitch**
Accept online paymentsGet started with accepting one time payments globally on your online storeonlinePayments.jpgquickstart
Setup mandates & recurring paymentsSetup payments for a future date or charge your customers on a recurring basisrecurringPayments.jpgsave-a-payment-method
Manage payoutsFacilitate payouts for global network of partners and service providersPayment flow (1).jpgpayouts
Save a card during paymentLearn how you can save your customers' cards in a secure PCI compliant mannersaveCard.jpgtokenization-and-saved-cards
Manage payments on your platform / marketplaceAccept payments from your customers and process payouts to the sellers on your marketplacemarketplace.jpgmultiple-accounts-and-profiles
Accept payments on your e-commerce platformGive your Wordpress store a lightweight and embedded payment experience with the Hyperswitch WooCommerce pluginWooComerce.jpgwoocommerce-plugin
Create payment linksAccept payments for your products through reusable links without writing any codepaymentLinks.jpgpayment-links
### **What are `PaymentIntent` and `PaymentAttempt` objects and how do they work in Hyperswitch?** 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. {% @mermaid/diagram content="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. {% @mermaid/diagram content="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 " %}