I'm using Authorize.net, not a customed payment module If you look at the code, you will see that the credit card number is temporarily stored in the cache. This means that cache is not just cache, but a requirement for Authorize.net credit card transactions to go through (a bad design, imho). What we were seeing is that customers couldn't get checked out, but their transaction ID was stuck in LINKED.
Our cache gets pretty full (we have lots of data, so I cache a lot of the queries). I increased the size and that seemed to work for a while but it started up again and, yes, the cache was pretty full. So I have started restarting memcache every night. Too soon to tell if that will work. On Fri, Aug 24, 2012 at 10:23 AM, Marconius Cuthemustard < [email protected]> wrote: > You mean the Order Payment object's Transaction ID is set to LINKED, > right? As far as I know, a *LINKED* order payment is created when you are > only doing authorizations on clients' cards instead of a final sale, which > is an authorization and a capture all at once. This method can usually be > activated by setting the CAPTURE setting to False in the Site Settings. > Your product orders should have *Order Payment Authorizations* in > conjunction with your LINKED payments. > > Did you write a custom payment module? I had a problem similar to this > when I first wrote my custom payment module. I was doing all the processing > in the views and listeners and not taking advantage of the Satchmo's > Payment Processor API. The result was that each order had one Payment > Authorization and *two *Order Payments set to Linked. It was weird. To > fix it I rewrote my module to use the processor class properly. > > Finally, I don't *think* that substituting Memchached will make a > difference, because all cache backends try to do the same thing (cache), > no? Maybe it would be better to use the never_cache decorator on some or > all of your checkout views like the *paypal* module does. > > > On Thursday, 23 August 2012 09:15:03 UTC-4, Mike Hostetler wrote: > >> So I increased our Memcache and that seemed to have worked -- for a >> while. But it happened again yesterday. I do think that is cache is related >> in some way, especially knowing that Satchmo stores the credit card >> number temporarily in cache during checkout. Maybe there is a cache miss >> during checkout that is causing this? >> >> I removed some of the views from cache (one has a big form in it, so I'm >> not sure it was cached anyway) to see if that helps. >> >> Does anyone use something besides memcache that works well? >> >> On Fri, Aug 17, 2012 at 1:08 PM, Orion Vianna <[email protected]>wrote: >> >>> IIRC, I had a lot of LINKED transaction ID problems when cashing and >>> memcached were not setup properly. >>> Maybe you are getting duplicate orders because users try again after a >>> unsuccessful checkout. I would check your cashing setup. >>> >>> Orion >>> >>> >>> On 08/16/2012 09:36 AM, Mike Hostetler wrote: >>> >>>> >>>> >>>> We have had a rash of orders that simply stay in the LINKED state -- >>>> sometimes they end up being duplicated as a charged orders but we also get >>>> some that stay at LINKED. >>>> >>>> We are getting more traffic (a good thing!) and more sales (a better >>>> thing!). Last night we had about 10 LINKED transactions and no actual new >>>> orders which is quite unusual. >>>> >>>> What causes a order to be LINKED? Why would it stay that way? >>>> >>>> >>>> -- >>>> Mike Hostetler >>>> SquarePeg Systems >>>> http://www.squarepegsystems.**co**m <http://www.squarepegsystems.com> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Satchmo users" group. >>>> To post to this group, send email to [email protected]****. >>>> To unsubscribe from this group, send email to satchmo-user...@**goog** >>>> legroups.com. >>>> >>>> For more options, visit this group at http://groups.google.com/**group* >>>> */satchmo-users?hl=en<http://groups.google.com/group/satchmo-users?hl=en> >>>> . >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Satchmo users" group. >>> To post to this group, send email to [email protected]****. >>> To unsubscribe from this group, send email to satchmo-user...@**goog** >>> legroups.com. >>> >>> For more options, visit this group at http://groups.google.com/**group** >>> /satchmo-users?hl=en<http://groups.google.com/group/satchmo-users?hl=en> >>> . >>> >>> >> >> >> -- >> Mike Hostetler >> SquarePeg Systems >> http://www.squarepegsystems.**com <http://www.squarepegsystems.com> >> > -- > You received this message because you are subscribed to the Google Groups > "Satchmo users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/satchmo-users/-/zEEEy27nQ6wJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/satchmo-users?hl=en. > -- Mike Hostetler SquarePeg Systems http://www.squarepegsystems.com -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
