Nars088

Maintainer here, this is the actual quiz we gave our new joinees while onboarding :)

Hyperswitch is on a mission to build payment infrastructure that serves billions of people at scale - a utility like water or electricity

True, still trying to fix that! Need to figure out how to implement 'show don't tell' with GPT

Thanks for the feedback (I'm a collaborator)

- We were thinking ideally the selection menu should take text input but parked that for later

Also the visualise buttons get enabled as soon as you hit generate button for the corresponding block!

It probably comes down to how many have actually added their cards to GPay and Apple pay, best to experiment and check if adding paypal improves your conversions

I also like not having a single payment provider have the ability to cut off my revenue if some kind of issue arises

How are you going about this currently? Have you integrated Paypal separately or do you have any other processor along with stripe?

Hyperswitch is free to use for the first 10k transactions of the month. After that it costs $0.04 per transaction. It is a payment switch that comes pre integrated with major processors. So as a merchant your business relationship with processors like Stripe or Adyen remains the same (I'm affiliated with this product)

I've seen some sites use Google maps API to suggest your exact address, pretty cool

I think there is a strong relationship between the average ticket size and payment experience. It is almost like it is the user's problem if the ticket size is high (hence the website need not necessarily invest in creating a good payment experience). Something like insurance websites.

The ones that really seem to think about the payment experience are the ones that have low to medium average ticket size and high transaction volumes. It is in the website's best interest to ensure each and every transaction goes through

Stripe's link has a similar experience

Can play with the layered shadows all day!

https://www.youtube.com/watch?v=5IUj1EZwpJY

True, it kind of depends on your current payment processor configuration.

For example if you find yourself in the need of accepting too many payment methods, you'll definitely benefit from the difference in fees for each method across processors

It also depends on your business focus. If you do not have the bandwidth to think beyond your core business, you might just be well off with a single processor

Currently do you use multiple processors though?

Check this out: https://github.com/rust-lang/rust/issues/111177

We spent decades trying to invent a sufficiently smart compiler when we should have been inventing a sufficiently empathetic one - @ekuber

It all makes sense now

Is this the case with all statically typed languages? I think I have faced the same issue with PureScript

(PS: I'm a contributor)

Yes that makes sense.

Have you considered using Stripe Elements? It has loads of customization options that you can configure using an appearance API

In that case I think it is just slightly more convenient to render a PCI compliant entity's frontend as an iframe inside your application and have it send the details directly to the processor's server, perhaps saves one additional hop

Yeah they can be. For example, Fiserv is an acquirer

What if network tokenization becomes more mainstream? If that happens browsers would't be able to vault users' card details

Yes but it is extremely risky for the business if Stripe or Paypal is its only processor. If for whatever reason your account is flagged by the processor, you wouldn't be able to accept payments

Okay this is a very comprehensive explainer and we keep coming back to this (I'm a contributor)

We recently launched an RFC process for our open source payments switch (written in Rust) and we put out our first RFC in the form of a GitHub Issue.

We did get some good feedback from Reddit but I am wondering if there is a more systematic way to do this. From your experience, what is the best way to facilitate such a discussion for large scale design decisions?

I. Objective

This RFC describes a novel payment method that effectively eliminates the need for any standardized medium that acts as a store of value. Elimination of this international standard is particularly useful for removing friction and latency associated with online payments.

II. Proposal

While institutional and technological advancements have revolutionized the way we transact, they have failed to remain backward compatible with primitive modes of value transfer within hyperlocal communities. Historically, these methods were deprecated due to the complementary demand problem but modern payment orchestration platforms can solve this through a network topology that simulates closed-loop commerce.

The payment method is presented as a wallet during the checkout. The user selects the method and uploads a merchandise artifact. Upon submission of the item, Hyperswitch servers dynamically scan a social graph connecting all live merchant accounts to create double coincidence of wants on demand.

Since physical items are non fungible in nature, Hyperswitch’s fraud engine authenticates the payment request before invoking the merchant graph for a match. Finally, the smart router determines the optimal delivery path and uses the merchant’s logistics rails for settlement.

III. Open Questions

What kind of fallback and retry mechanisms can be incorporated? What is the feasibility for recurring payments, payouts and refunds? Can the transaction units be tokenized?

IV. Additional Context

The wallet in this case takes a more tangible form factor as opposed to traditional e-wallets. They are basically warehouses for the physical transaction units. Note that this method eliminates the need for PCI compliance altogether, thereby creating a truly open payments ecosystem. At its core, the payment flow fosters the fundamental human tendency to form patterns of interdependent sharing of resources.

I. Objective

This RFC describes a novel payment method that effectively eliminates the need for any standardized medium that acts as a store of value. Elimination of this international standard is particularly useful for removing friction and latency associated with online payments.

II. Proposal

While institutional and technological advancements have revolutionized the way we transact, they have failed to remain backward compatible with primitive modes of value transfer within hyperlocal communities. Historically, these methods were deprecated due to the complementary demand problem but modern payment orchestration platforms can solve this through a network topology that simulates closed-loop commerce.

The payment method is presented as a wallet during the checkout. The user selects the method and uploads a merchandise artifact. Upon submission of the item, Hyperswitch servers dynamically scan a social graph connecting all live merchant accounts to create double coincidence of wants on demand.

Since physical items are non fungible in nature, Hyperswitch’s fraud engine authenticates the payment request before invoking the merchant graph for a match. Finally, the smart router determines the optimal delivery path and uses the merchant’s logistics rails for settlement.

III. Open Questions

What kind of fallback and retry mechanisms can be incorporated? What is the feasibility for recurring payments, payouts and refunds? Can the transaction units be tokenized?

IV. Additional Context

The wallet in this case takes a more tangible form factor as opposed to traditional e-wallets. They are basically warehouses for the physical transaction units. Note that this method eliminates the need for PCI compliance altogether, thereby creating a truly open payments ecosystem. At its core, the payment flow fosters the fundamental human tendency to form patterns of interdependent sharing of resources.

One approach we started with was to look at external dependencies and reduce the depth of the crate dependency tree. Past improvements like removing redundant feature flags from diesel resulted in a significant improvement in compile time. Overall, we are looking to improve the developer experience through faster compilation for local setups. We at Hyperswitch (an open source payments switch) have just issued our first RFC to improve our compile time and improve compilation performance with low resource machines. From your experience, what are some of the approaches that you would consider effective?

Hi all, HyperSwitch is an Open Source Financial Switch to make payments Fast, Reliable and Affordable. Built on Rust, it lets you connect with multiple payment processors and route traffic effortlessly, all with a single API integration. We have launched today on product hunt and are currently trending at #1. Can't wait for everyone to try it out :)

Update: So we launched on product hunt today and are currently trending at #1 Do checkout our post and upvote if you like it :) https://www.producthunt.com/posts/hyperswitch-2