All had commits in November (so ~2 months ago), have zero releases, and between 35-80 commits with a handful of committers … so all are similarly active, it seems.
All implement support for only one payment gateway, however … PayPal or Stripe, depending on the one. This leaves me scratching my head, and so I figured I’d lazyweb this and see if any of you have experience with the above libraries.
If so … what was your experience like? (Usage, quality, issues, upstreaming fixes / improvements …)
On a more philosopical level, I do wish there was one good, (more) complete solution rather than three unfinished options … but I’m used to both open source and new-tech ecosystems, so I’m not surprised … my kingdom for a better world, and all that
https://github.com/joshnuss/commerce_billing is modeled after active merchant and actually supports 2 gateways so looks like a leader as of now one of the gateways is bogus though
I had this same frustration at the end of last year which is why I started the cashier repo with the aim to continue adding gateways. Sadly as always I ran out of time leading up to Christmas and haven’t yet had chance to pick it up again this year.
I still aim to maintain this project moving forwards and complete the first release including the PayPal gateway initially. If anyone is interested in contributing either with testing or developing please do me know and I will assist in anyway I can.
Nice to hear that you want to continue developing cashier. Looking at the code, I do have some questions/concerns regarding the supervisor tree design and use of sync calls. I’m still looking through the various options, but if I were to offer some feedback where you prefer that to happen? (email, github, here on the forum …?)
I also have concerns regarding the current design which I don’t see working in a production environment, especially as a purchase request to paypal can seem to take up to 6 seconds. I have just started creating issues (more still needed) on the repo to track what work needs to be done to get to v1, which might be of interest to you.
I was very new to gen server when I set out on this, so much of whats there was more of a learning exercise. I would very much welcome any feedback or suggestions you have, best places are either a thread on this forum, github issues or I have already setup a gitter chat room.
Cool; you may hear from me over the weekend Having a relatively complete, reliable and easy to use solution would be rather nice to have …
I’m also interested in being able to do payments from a Phoenix.Channel and possible also from a mostly-GraphQL application, so I need to look into what sort of requirements that will bring (beyond the obvious things like async calls being preferable …)
Did you use braintree drop-in UI or custom form? any pointers or reference on how to go about the implementation would be really helpful.
I am working on my first App in Elixir. I am using https://github.com/sorentwo/braintree-elixir and npm package npm package “braintree-web-drop-in”. Coming from RoR world, I am still trying to wrap my head around how FP world works!
I’ve the author of the Braintree library and have used it in a couple of production environments.
In my experience the only tricky part of integrating with a front end form is generating a client_token, which is documented here: Braintree.ClientToken. It is possible to share the token between requests by caching it with an Agent or ETS, which can prevent the server from hitting Braintree every time the form loads.
Thanks @sorentwo for the prompt response and the wonderful library.
BTW, there have been some changes on Braintree side, where they have moved things from class-level methods to instance methods for Ruby, Python and PHP SDKs - https://developers.braintreepayments.com/reference/general/class-level-vs-instance-methods/ruby. The call needs to be gateway.clientToken.generate once the new instance is created. Not sure if any changes are required in your library though.
The API endpoints have remained the same, so we are safe there. The official libraries are all for OOish languages that have methods and a distinction between class and instance level calls. That doesn’t directly apply in a functional language, all we have is namespacing.