Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW
 
PerlMonks  

How to safely/atomically process payments

by Anonymous Monk
on Nov 12, 2013 at 07:27 UTC ( #1062132=perlquestion: print w/replies, xml ) Need Help??

Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I've got an application that processes payments using Stripe.com. The problem is that occasionally the payment will process successfully, but then there is a database error that prevents me from saving the payment details. What is the best way to handle a situation like this to ensure that I don't end up with side effects outside of my application (orphaned credit card charges, etc) ?
  • Comment on How to safely/atomically process payments

Replies are listed 'Best First'.
Re: How to safely/atomically process payments
by kcott (Archbishop) on Nov 12, 2013 at 07:47 UTC

    That's insufficient information on all fronts: what code? what input? what output? what conditions are successful? what conditions are unsuccessful? what are the errors?

    See the "How do I post a question effectively?" guidelines to find out the correct information to post and how to post it.

    -- Ken

      That's insufficient information on all fronts: what code? what input? what output? what conditions are successful? what conditions are unsuccessful? what are the errors?

      I think there is. Its a strategy question (what do when remote process wins and local logging fails), not a code question, it doesn't require code

        Your interpretation of the question clearly differs from mine. That's fine.

        If the question boils down to: "How do I use SomeApp under certain conditions?", then SomeAppMonks (or equivalent) would be a more appropriate place to post the question than PerlMonks.

        On the other hand, if the question boils down to "How do I use Perl to interface with SomeApp under certain conditions?", then PerlMonks would be appropriate and the information provided remains insufficient.

        Let's wait for the OP to clarify this.

        -- Ken

Re: How to safely/atomically process payments
by Anonymous Monk on Nov 12, 2013 at 07:45 UTC
    What does stripe.com recommend? I'd be surprised if stripe.com didn't exactly outline what to do in this scenario, like cancel the payment or something
Re: How to safely/atomically process payments
by kschwab (Vicar) on Nov 12, 2013 at 12:26 UTC

    Stripe.com's API allows you to pull historical lists, like "all customers", "all charges" (with optional date ranges), etc.

    There's also an event API where you could have a separate server collect and log everything

    So, the only thing you might lose is track data, card number, etc. Things you shouldn't be keeping anyway.

    Or maybe you're talking about data that's related to the order? Like what items were sold, customers shipping address, etc? Personally, I wouldn't roll back a purchase just because I couldn't write to a local database. Log it remotely, or to a local file. Or use Stripe's metadata field.

    That said, Stripe.com's 2.9% + $0.30 is a horrible rate. You can do much better. Their big differentiation is the feature rich API. If you don't truly need that, look elsewhere.

Re: How to safely/atomically process payments
by barrd (Canon) on Nov 12, 2013 at 08:08 UTC
Re: How to safely/atomically process payments
by boftx (Deacon) on Nov 12, 2013 at 19:14 UTC

    This is a problem that has haunted pay sites for many, many years (as well as my dreams for that amount of time.)

    The general case solution is to get a transaction "token" or ID number from the processor in advance of sending the actual transaction. Once you have the token (assuming Stripe supports this) you can log it along with an internal transaction ID and then send the transaction data along with the token included. By logging the token associated with a given transaction, you can then run a fairly simple cron job at regular intervals to see if any tokens have not been returned in a processed transaction and take steps as needed from there to rectify the problem.

    I realize that this is a vague response, but keep in mind that this very problem has kept many programmers employed (and up late at night) for a long time now. A similar problem has been the notorious "double-click" form submission that could result in a double-billing. If this is a serious problem you could probably advertise on http://jobs.perl.org and find a competent person to help you resolve it.

    The answer to the question "Can we do this?" is always an emphatic "Yes!" Just give me enough time and money.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://1062132]
Approved by kcott
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (1)
As of 2022-07-01 22:52 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    My most frequent journeys are powered by:









    Results (102 votes). Check out past polls.

    Notices?