Direct Payment Control Model
Best for merchants who do not want to handle card data and want to maintain their current integration with the processors.
In this approach, the Direct Payment Control Model functions by treating Hyperswitch as a secure "pipe." This setup grants you full control over your orchestration logic and the specific API calls sent to processors. The process initiates when the customer enters payment details into the Hyperswitch Vault SDK, where the data is directly tokenized within the Hyperswitch Vault.
For payments, your backend constructs a request intended for your specific processor, such as Stripe or Adyen, utilizing placeholders instead of raw card data. This request is then routed through the Hyperswitch Proxy. The proxy injects the actual card details immediately before forwarding the request to the processor, ensuring that raw card data never touches your servers.
This architecture allows you to maintain your legacy backend logic while significantly reducing PCI scope. It is particularly well-suited for scenarios where you plan to keep existing processor integrations. but require the removal of sensitive card data from your internal systems.
Understanding Payment and Vault Flow
Vaulting :
In this flow the card is first stored and a token is generated. Sensitive payment data is sent directly from the Vault SDK to the Hyperswitch Vault and you receive a non-sensitive token in return which will use to initiate payments.
Making Proxy Payment
Custom Orchestration: Your backend decides exactly when and where to process the payment.
Secure Passthrough (Proxy): When you are ready to charge, you send the request to the Hyperswitch Proxy API along with the payment method id, targeting the processor's native endpoint.
Redaction & Injection: The Proxy identifies the token in your payload, injects the real card data from the Vault based on the payment method id, and forwards the full request to the processor.
Integration Documetation :
Last updated
Was this helpful?