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.

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

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.

stripe.com provide quite detailed docs and by using their support pages you can refine your search.

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.