Issue #10 resolved

add external merchant services reports

Dominic Cerquetti
created an issue

We have a good offer on the table from suntrust bank for merchant services through authorize.net. I'd like to move away from paypal for payments ASAP because it's a huge nightmare on the accounting backend side, and one day paypal is gonna freeze our account for no good reason leaving us holding the bag for tens of thousands of dollars.

There's a loooooot of research to be done and a huge restructuring of the ubersystem payment code, probably.

Comments (12)

  1. EliAndrewC repo owner

    I agree that we need to do this. Hopefully I'll have time to make this happen this year even if I have to do all of the research and whatnot.

    Right now our workflow is basically this: - someone preregisters - we show them a Paypal button they can use to Pay - they pay, and then one of several things happens: -- the payment might go through immediately -- the payment might be an eCheck and therefore pending -- the payment might be held up due to a payment review -- the payment might go through and then be reversed later

    So the reversed thing is very rare; it happens only a couple of times per year and we just manually handle it, e.g. email the person and figure out what's happening. This will probably be the same for accepting credit cards, so I doubt we'll have any increased complexity there.

    I don't know whether credit/debit card payments always go through immediately or what. I mean, I'm sure there's some notion of a payment review that can happen, but I don't know if that means that the money has been transferred and then is frozen pending the review, or what.

    Most importantly, when any of this happens with Paypal, they hit our callback URL. I have no idea if that's how credit card processing would work, or if we'd query against their API every few minutes, or what. That's the main question; the code will probably be fairly simple either way; the "business logic" for our entire prereg backend is only a few hundred lines of code, so I'm not that worried about a rewrite.

    Dom, if you could point me to where you think I should look to answer these questions, that'd be great. I may also check out Stripe.com, which I've heard nothing but great things about in terms of how easy it is to take credit card payments.

  2. EliAndrewC repo owner

    After spending 5 minutes reading the Stripe.com documentation, I feel super-confident that we could switch to using Stripe with a tiny amount of effort. Our code would end up being shorter and simpler than the Paypal code ever was, and a lot of features would be a lot easier to implement. I can see from their developer docs exactly what my Python code would look like and how I'd hook the form into our prereg process on the client.

    After spending a few minutes reading through the Authorize.net docs, I have no idea how easy or hard any of this would be, and there are no code samples anywhere obvious. So unless they're offering us a WAY better price than Stripe (which charges 30 cents plus 2.9%) we should probably just go with Stripe: https://stripe.com/us/help/pricing

  3. Dominic Cerquetti reporter

    The SunTrust price is way better than stripe but not as worried about the fees vs picking the better service for us.

    I'll do some homework. I recall auhtorize.net had an option that was basically identical to the paypal callback system

  4. EliAndrewC repo owner

    At this point, "works like Paypal" is probably a downside. By which I basically mean, Paypal's workflow makes a bunch of stuff a lot harder, and it would be much easier to just have a "charge $X and then do something" interface, as opposed to a "set the amount owed to $x, then give someone a payment link, then wait until you get a callback". Doing things that way makes a bunch of features a lot more annoying.

  5. Dominic Cerquetti reporter

    Oh sorry not necessarily the "wait for the link later" but it "works like paypal" in that you get a callback whether the payment went through or not.

    They type their payment info into our form, but the POST goes to the authorize.net server. That server then hits our server a few seconds later with whether the payment went through or not.

  6. EliAndrewC repo owner

    So I've created a test account with Stripe and integrated their code into our prereg process. I've got some more work to go, error handling and such, but overall it was pretty easy and is working great. I'll throw up a test site so people can see it as soon as things are stable enough.

  7. Dominic Cerquetti reporter

    Btw, quick note. I'm down for anything that fits the requirements for payment services which are as follows:

    1) ANYTHING THAT'S NOT PAYPAL

    So, in that sense, Stripe is totally fine : )

    I will say though that the offer on the table from Suntrust's merchant services beats the pants off of Stripe's rates of "2.9% + 30 cents per successful charge". This is akin to saving somewhere between $2000 to $4000 a year in processing fees.

    Buuuuuttt...... I don't actually care, I just want to get the fuck away from paypal for serious amounts of processing. If you already have something working with Stripe, let's just go for that. I'm really glad you had the chance to knock this out.

  8. EliAndrewC repo owner

    Yeah, I realize that Suntrust might save us a lot of money, and I'm definitely writing the code such that we could theoretically swap out Stripe for something else, i.e. there are only two methods that I'd have to change to switch to a different provider assuming they integrated as easily as Stripe. But it was super-easy to set up a test account with Stripe, get a developer key for testing, add their Javascript to our page, and use their test credit card number (4242 4242 4242 4242) to add credit card payments to prereg.

    So I figure I'll finish all of the other development work we need to get done before prereg goes live, and then we can circle back to the question of credit card providers, and if Suntrust is just as easy as Stripe, then we can swap it out, and if it's not then we can stick with Stripe.

  9. EliAndrewC repo owner

    At this point all of the coding for Stripe integration is done, so I'm marking this as resolved. We still need to connect Stripe to our bank account and whatnot, and obviously we can still use other vendors if we want, but honestly I don't think it will be worth the hassle.

  10. Log in to comment