Hacker News Reader

Comment by dcsoft | Hacker News Reader

I am a current Kagi supplier, and this unexpected closure has me in a bad place. It took a few days to code my system to interface with theirs and to generate licenses automatically for each purchase. I suppose I need to redo all that.

I appreciate Kagi for their years of friendly and comprehensive service as well as the next person, but why didn't Kee Nethery support us better during the closure? No migration path to or even recommendation of a replacement. Where are others moving their payment processor to?

And it sounds like we may not get fully paid either.

View on HN

If you don't mind do a bit of coding:

  * Stripe
  * PayPal. (You want the "Express Checkout" workflow)

(Hint: for increased sales offer both. Stripe is a developer's dream; adding PayPal adds perhaps 30% more sales, although YMMV)

If you want someone else to take care of all the details in return for higher commission:

  * FastSpring (full service, heavyweight)
  * Paddle (streamlined, focused towards Mac and towards digital products such as ebooks)
  * Gumroad (focused on info products)
  * SendOwl (you still need your own Stripe and/or PayPal, but you don't need to do the coding. They give you a polished, modern feature-rich UI on top of your payment processor.)

> Stripe is a developer's dream

Unless you're using the JVM. Their Java API is so awful that it feels like you're just shelling out to cURL.

Have you tried PayPal? Stripe's Java library may be a bit simplistic but at least the fundamental API concepts are sound.

(I'm a developer at Stripe who helps maintain our language bindings.)

+1. The original system was designed to be as flexible as possible and had the advantage of being able to support many different integrations that were straddling many different versions of the Stripe API, and all from within a single version of the Java library.

Its major downside of course is that the same flexibility somewhat compromises the developer experience, and the choice hasn't mapped well onto languages like Java where the expectation is that most functionality should be discoverable by the type system.

If it's any consolation, we're certainly aware of the problem and have a rough plan/roadmap on how to address some of the more appalling blemishes in usability.

I used Stripe's Java API for my website. I wouldn't say it was awful - it got the job done, and exception handling was well thought out. But it wasn't idiomatic Java. It felt like it had been put together by someone who knew a language other than Java really well.

No higher commission & no coding option:

* JotForm (+Stripe or +PayPal)

Depending on your situation, you might want to lean towards FastSpring or the other full services - from memory one of Kagi's value-adds was collecting the appropriate tax when selling to certain countries (ie collecting and remitting VAT when selling to customers in the EU).

[I'd actually recommend talking to FastSpring - they used to provide a concierge service to setup the order form for you, and they have a system where they can ping a licence key generator on your server (eg in PHP), much like what Kagi did. I'm happy to try to answer questions if you or anyone else gets stuck, contact details in my profile.]

Seconding this recommendation. I'm a Mac developer and sell shareware, but have very little web development experience. I switched from a (pretty thrown together) implementation using Paypal to Fastspring a few years ago, and the process could not have been smoother. Fastspring was super helpful getting me set up, and I had to do very little work to get my existing (PHP) license generator integrated with their system. I've been a satisfied customer ever since.

Just a warning: when some subscription-management service advertises they support PayPal Express Checkout/Payments Pro make sure to check the exact requirements.

Many require reference transactions support. Which requires PayPal approval, and (from what I understood from the person who actually talked with PayPal) they only give it after some revenue levels that aren't trivial to achieve if you're just starting and don't even have any sales yet.

When coding on their own, interfacing PayPal directly, one can avoid this requirement, settling for a somewhat more limited but still fairly functional set of EC APIs.

Full disclosure: I'm a payment processor.

Your best bet is Stripe in most cases. They have a robust API, and a simple payment scheme as far as handling interchange and fee structures. However, it makes sense to find someone like myself (a dev payment processor) when you fill two critera: 1) an average transaction size of $25 or greater, 2) a monthly transaction volume of over $5,000. Until both of those criteria are met, it makes more sense to process through Stripe or Square because their fees will be lower and there is more hand holding on the API side.

I board most of my business with Priority Payment Systems because they have an API that I like, with lots of documentation and good relationship managers. This is just my opinion based on my years in the payments and development space, so do some searching before you settle with something.

imho the main service of Kagi (and similar services) was not payment processing, but robust and secure licence key fulfillment.

I am a Kagi supplier too. Although I stopped selling with them some time ago, I still have a lot of customer data in their database. I was surprised to hear of the closure and received no notification from them.

I have been using Share-It for over five years. They have a solid system for running licence generators and although it's not the most modern, I can recommend them as an equivalent service to Kagi. If you sell in the EU you'll want to check the fine print on their VAT policies.

Avangate and BlueSnap are two other full service options, I'm using both at the moment as I don't like to have all my eggs in one basket.

Might want to try out fastspring.com

Reply on news.ycombinator.com