During the transition phase of Hyperswitch, Merchant should be able to send the processor's token to Hyperswitch to process MIT transaction. This is because, Merchant will not have the card data to migrate from Processor to Hyperswitch.
Possible Implementation
#Solution 1
In payments create+confirm API, we will add new enum processor_token in type under recurring_details to support connector data. We will start supporting Bambora’s and we will slowly adopt every connectors.
This field will be a replaceable field for payment method id. Merchant can either pass payment_method_id or {recurring_details.data:{processor_payment_token: "value", connector:"BAMBORA"}}. Connector can be enum.
Based on this field, we will fork the main flow, which will skip the payment_method part and use this data given in the request.
Expected Flow:
Merchant needs to create customer before calling this API.
Call Payments API
Technical changes information:
Routing is not involved - (No changes)
Customer related process can also be ignored. (No changes, as merchant creates customer before calling this API)
Populate connector_mandate_id in router_data from the request, instead of fetching from database.
In V1 we can add if else to handle the flow, in v2, we will follow separate handler with the same route.
Flow shall be in the following order,
Get tracker (create+confirm)
Get customer (create + confirm)
Skip to call connector (create + confirm).
response handling (create + confirm )
Have you spent some time checking if this feature request has been raised before?
Feature Description
During the transition phase of Hyperswitch, Merchant should be able to send the processor's token to Hyperswitch to process MIT transaction. This is because, Merchant will not have the card data to migrate from Processor to Hyperswitch.
Possible Implementation
#Solution 1 In payments create+confirm API, we will add new enum processor_token in type under recurring_details to support connector data. We will start supporting Bambora’s and we will slowly adopt every connectors.
This field will be a replaceable field for payment method id. Merchant can either pass payment_method_id or {recurring_details.data:{processor_payment_token: "value", connector:"BAMBORA"}}. Connector can be enum.
Based on this field, we will fork the main flow, which will skip the payment_method part and use this data given in the request.
Expected Flow:
Technical changes information:
router_data
from the request, instead of fetching from database.In V1 we can add if else to handle the flow, in v2, we will follow separate handler with the same route.
Flow shall be in the following order,
Have you spent some time checking if this feature request has been raised before?
Have you read the Contributing Guidelines?
Are you willing to submit a PR?
None