We wish to create a Connector to talk to our payment solutions and integrate them as part of Hyperswitch

[MarkCupitt]

We want to commit to Hyperswitch as our Payments Orchestrator, running in a Kubernetes Cluster that provides payment solutions to our multi-tenanted billing system.

We have/are developing custom payment solutions with services like PaymentsNZ and we are targeting operations in the Philippines, and we can see there may be a need to integrate with multiple micro - payment providers.

It seems that we may best present ourselves as a "Payment Processor" which provides for multiple Payment Services and connects to Hyperswitch using that presentation

I understand a connector needs to be written in Rust, and is a lightweight stateless interface between hyperswitch and payment systems we will develop over time in our Billrush Billing Solution

We have started our project to achieve this and would appreciate any help you can offer on the OSS version, specifically documentation on how the connector should be structured and function, and perhaps some samples of the code.

We will be deploying Hyperswitch in Kubernetes using the Helm Chart,m but as I understand it, the connector will need to be integrated into the core code?? and the service will need to be rebuilt as a customer image, is that correct?

Many thanks in advance for any help, feedback and pointers

Mark Cupitt
Head of Global Operations
Billrush

[MarkCupitt]

I just found the COnnector Template in the Repo :) so it would just be any documentation that may be available

[MarkCupitt]

And I finally found the add_connector.md doc in the repo as well ...

[srujanchikke]

Yes @MarkCupitt ,this will generate template code for new connector .In case you have any queries, you can ask them on this issue thread, or on our discord server, or on slack whichever you are comfortable with

[MarkCupitt]

Thanks heaps, Ill keep this open for now, Rust is new to us so it will be a slow start

[srujanchikke]

To enhance the open-source development experience, we have recently developed an Infrastructure-as-Code (IaC) script for deploying our full-stack application on AWS within an hour. You can find the details and instructions at here. Utilizing this script will enable you to get started quickly.
Prerequisites for Running the Script:
-> Operating System:
1)Mac or Linux machine (It is recommended for running the deployment script).
-> AWS Account:
1)You need an AWS user account with non-root access.
2)The user should have admin access to ensure all required permissions for deploying resources.

If you prefer using only HelmChart for deployment, you can refer to the HelmChart solution at here.

[MarkCupitt]

FOr your Docs, to get the add_connector script to work, I had to rustup toolchain install nightly. Otehrwise relatively straight forward to get a local dev version running

[MarkCupitt]

When running add_connector, I am now getting this error error[E0004]: non-exhaustive patterns: RoutableConnectors::Billrush not covered .. am researching it, another one for the docs, I guess we are missing something,

Looks like based on the error message, its saying this needs to be added to the api_models/routing.rs, I guess the script is not doing that?? SHoudl we add it manually?

RoutableConnectors::Billrush => euclid_enums::Connector::Billrush,

This is the command Im using, based on the docs

bash add_connector.sh billrush http://localhost:8765

Full log follows:


  Compiling api_models v0.1.0 (/home/mark/repos/billrush/BOUNTY/hyperswitch/crates/api_models)
error[E0004]: non-exhaustive patterns: `RoutableConnectors::Billrush` not covered
   --> crates/api_models/src/routing.rs:290:30
    |
290 |             connector: match value.connector {
    |                              ^^^^^^^^^^^^^^^ pattern `RoutableConnectors::Billrush` not covered
    |
note: `RoutableConnectors` defined here
   --> crates/api_models/src/enums.rs:168:5
    |
167 | pub enum RoutableConnectors {
    |          ------------------
168 |     Billrush,
    |     ^^^^^^^^ not covered
    = note: the matched value is of type `RoutableConnectors`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
    |
352 ~                 RoutableConnectors::Zen => euclid_enums::Connector::Zen,
353 ~                 RoutableConnectors::Billrush => todo!(),
    |

For more information about this error, try `rustc --explain E0004`.
error: could not compile `api_models` (lib) due to previous error
warning: build failed, waiting for other jobs to finish...
```

[MarkCupitt]

More info, I can see in the add_connectors script where the connector is added to some files using sed, but cannot see where its is added to the crates/api_models/src/routing.rs file ..

Here is what is there now ..

sed -i '' -e "s/\(pub enum Connector {\)/\1\n\t${payment_gateway_camelcase},/" crates/api_models/src/enums.rs
sed -i'' -e "s/\(pub enum RoutableConnectors {\)/\1\n\t${payment_gateway_camelcase},/" crates/api_models/src/enums.rs
sed -i'' -e "s/^default_imp_for_\(.*\)/default_imp_for_\1\n\tconnector::${payment_gateway_camelcase},/" $src/core/payments/flows.rs

[srujanchikke]

Hi @MarkCupitt,

Thank you for reporting the bug. We recently introduced routing in our repository, and I have opened an issue for it (#2961). If you wish to rely on the template script, we can address the issue in a couple of days.
If you need to go ahead with integration right away, you can manually add the connector enum at

hyperswitch/crates/euclid/src/enums.rs

Line 56 in 203bbd7

pub enum Connector {

and fix the errors thrown by the compiler about a missing match arm.

Additionally, please change the return type to CustomResult<Box, errors::ConnectorError> for the function get_webhook_resource_object in the connector.rs file.

[MarkCupitt]

@srujanchikke We wil implement your suggestions in the short term, but we would like to use the template script when it's fixed ..

One other thing I did notice, there is no easy way to "Remove" a connector, currently I'm stashing changes and starting again, some docs or pointers on a way to do this would be appreciated if possible

[srujanchikke]

Could you please provide information about the payment methods you plan to integrate via Billrush? If you are considering non-3DS card payments, we have an internal tool that allows you to generate Rust code simply by providing the cURLs for the payment flow. Additionally, the tool opens a pull request in our repository on your behalf. We can have this tool ready for you within a couple of days and make it accessible.

[euluizaraujo]

@srujanchikke Hello, we are starting to implement other payment methods and this tool would also help us a lot. How can we gain access?

[MarkCupitt]

@srujanchikke Thanks for the feedback and suggested bug fixes .. a little background on what we are doing. I work for Billrush, a Billing Solutions Provider based out of New Zealand (https://billrush.co.nz). I am the Head of Global Operations. We recently decided to commit to Hyperswitch as our payments orchestrator after a several month look at our available options.

We are a bare metal kubernetes managed SAAS provider and we will be deploying Hyperswitch into our clusters to replace our current solution.

Our immediate target markets are NZ, Australia and the Philippines and we are in active discussions with partners in those markets.

We have identified that there will never be a one size fits all payment solution, one of the attractions of Hyperswitch to us was the ability to extend it to add more providers specific to our needs.

We will have a strong focus on Open Banking and Micro Payments services as our motto is "From Bill to Bank". Our goal is to make the payment solutions as seamless and as flexible as we can for our customers.

Our platforms are multi tenanted and we need to account for regionally specific requirements around payment tracking receipt issuance and so on, on a per tenant/location basis. Hyperswitch will give us the opportunity to align out integration and custom payment solutions to support this requirement.

We currently have a solution (in Java) for Payments New Zealand (NZ Open Banking) and we have decided to refactor/rewrite this in a manner that will integrate with Hyperswitch. Our intention is to eventually Open Source this code!

We will use existing providers in Hyperswitch for all CCards, we don't wish to reinvent the wheel, our focus will be on providing payment solutions that are not satisfied by current options, or are specific to our platform/customers ..

Having said that, we are a strong advocate for open banking, as you probably know Open Banking is not so open, with each country and region having their own "flavour" and we would be very interested in partnering with Hyperswitch once our Rust experience increased to a satisfactory level and our need for an Open Banking solution in a specific region arises ...

One suggestion I have would be for you to is to consider providing a "Generic" Connector that would interface with customer connectors via apis .. (Plugin Pattern) It would require data in specific formats so the need for mapping was removed, the connector would be responsible to ensure the data was in correct format.

This would remove the need for companies like us to invest in Rust resources, which is totally new to us .. We could implement the connector in whatever language we wished .. Im not sure how well this fits your development model, but it would sure help us (and probably others) to make the most use of hyperswitch as a solution

Hope that helps, please let me know if you would like any more information and Im very much looking forward to getting our implementation under way. We are targeting to have it in soak testing with PaymentsNZ before Feb Next year

Regards

Mark Cupitt
Head of Global Operations
Billrush

[srujanchikke]

Hi @euluizaraujo and @MarkCupitt ,

Thank you for the recommendations. We are in the process of updating our connector documentation. Our organization has been using an internal connector automation tool, and we are currently engaged in a refactoring effort aimed at improving the overall development experience. Once this refactoring initiative is complete, I will promptly share the comprehensive documentation related to the automation tool with you. Your valued expertise and insights during this phase are greatly appreciated.

[euluizaraujo]

@srujanchikke hello! While we do not make this tool available, is it possible to provide an overview of it to help us create new connectors? This way, we can help each other evaluate the possibility of developing something similar and making it available to the community.

[srujanchikke]

Hello @MarkCupitt,

We're still trying to grasp the position of our hyperswitch within your architecture. It would be beneficial if you could provide a simplified architecture that clearly outlines the roles of the Customer, Hyperswitch, Billrush, and Openbanking.

[MarkCupitt]

@srujanchikke Its pretty straight forward, we are a Multi Tenanted SAAS Billing Platform, we have customers, they have Customers, we will provide Billing and payment solutions for our customers to collect on behalf of their customers .. We will use paymentsNZ (which is NZ Open Banking) to provide payment options as one of many our Customers may choose to enable on Hyperswitch .. We will provide the PaymnetysNZ payment method via a connector on Hypoperswitch. We will likely add additional payment methods if unsupported by HGyperswitch or specific to your Customers

Hyperswitch will be deployed in multiple Kubernetes SAAS CLuster originally scoped Globally.

It is not OpenBanking as you understand it, it is PaymentNZ, which is a NZ Specific OpenBanking initiative. We will likely offer other open banking connectivity in the future, as I said earlier, we may be interested in working with Hyperswitch on that aspect. Payments NZ id only the first paymenthod we will implement.

Not really sure what else I can tell you .. What are you concerns? Perhaps if you detailed those, I can address them, specifically ???

[MarkCupitt]

@srujanchikke If you want to consider Ayden, we will likely implement a similar approach to that Connector, one Payment Provider, named Billrush, many Payment Methods. Open Banking in NZ is done via PaymenstNZ registration and verification, however each bank will be displayed as a separate p[payment method as we will work with their specific apis. (eg: OpenBanking-BNZ, OpenBankig-ANZ and so on

[srujanchikke]

Hi @MarkCupitt, Yes you can refer for adyen as payment provider and implement banks as payment methods.

[srujanchikke]

Hi @MarkCupitt and @euluizaraujo, open-sourcing of the connector automation tool might take additional time. In the mean time fix for connector template has been implemented and is now available in the latest main branch.

[MarkCupitt]

Thanks heaps @euluizaraujo

[MarkCupitt]

@euluizaraujo Happy to let you know that the build did work, of course, it failed all the 20 tests, to be expected at this stage :)

Thanks heaps, we will move forward