HNHacker News
TopNewBestAskShowJobs

Narsagna

131 karma · joined November 9, 2020

submissionscomments
Narsagna··on Ask not what the compiler can do for you
Check this out: https://github.com/rust-lang/rust/issues/111177
Narsagna··on Ask not what the compiler can do for you
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

Narsagna··on Ask not what the compiler can do for you
Is this the case with all statically typed languages? I think I have faced the same issue with PureScript

(PS: I'm a contributor)

Narsagna··on Payments 101 for a Developer
Yes that makes sense.

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

Narsagna··on Payments 101 for a Developer
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
Narsagna··on Payments 101 for a Developer
Yeah they can be. For example, Fiserv is an acquirer
Narsagna··on Payments 101 for a Developer
What if network tokenization becomes more mainstream? If that happens browsers would't be able to vault users' card details
Narsagna··on Payments 101 for a Developer
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
Narsagna··on Payments 101 for a Developer
Okay this is a very comprehensive explainer and we keep coming back to this (I'm a contributor)
Narsagna··on How to best run an RFC (Request for Comments) process?
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?

Narsagna··on Merchandising by Exchange as a Payment Method
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.

Narsagna··on Merchandising by Exchange as a Payment Method
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.

Narsagna··on RFC: Improving compile time of Rust project
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?
Narsagna··on [dead]
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 :)
Narsagna··on Hyperswitch – Connect to multiple payment processor with a single API
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
← PreviousPage 2 of 2