Paypal Payment but No Order Recorded

------=_NextPart_000_00D7_01C52E6A.3DA39930
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I received two orders today where I received the paypal payment =
confirmation, but I did not receive an order confirmation and one was =
not recorded in the admin. I have read that this is a common problem. =
I am wondering what exactly my customers need to do in order for this =
not to happen. I am hoping to put some instructional words into the =
footers, but I need to know what they have done wrong before I can help =
them out. Any ideas? Thanks.

------=_NextPart_000_00D7_01C52E6A.3DA39930--

Paypal Payment but No Order Recorded



They didn't click on the Continue button at the end of process, where it
takes them from the PayPal site back to your site. A very common problem.
You can instruct your users to "BE SURE TO CLICK THE FINAL CONTINUE BUTTON
TO RETURN TO THIS SITE. YOUR ORDER IS NOT COMPLETE UNTIL YOU ARE RETURNED TO
THIS SITE." Or, you can take the burden off your customers with one of these
modules, which will get you the order data even if they don't click that
last Continue button:

<A HREF ="http://www.mivacentral.com/doubleplus/?product=VCS-BROK_PAYPAL">http://www.mivacentral.com/doubleplus/?product=VCS-BROK_PAYPAL</A>

<A HREF ="http://www.mivacentral.com/doubleplus/?product=WCW-PAYPAL">http://www.mivacentral.com/doubleplus/?product=WCW-PAYPAL</A>

Chuck

-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Creative Crafts and Stickers (Jen Walker)
Sent: Monday, March 21, 2005 11:04 PM
To: [email protected]
Subject: [mru] Paypal Payment but No Order Recorded

I received two orders today where I received the paypal payment
confirmation, but I did not receive an order confirmation and one was not
recorded in the admin. I have read that this is a common problem. I am
wondering what exactly my customers need to do in order for this not to
happen. I am hoping to put some instructional words into the footers, but I
need to know what they have done wrong before I can help them out. Any
ideas? Thanks.

Paypal Payment but No Order Recorded



That is what I thought for years, however, recent investigations show that
this is not the case, at least with Viking and Weiland's modules as they
post back when payment is committed in paypal (the screen before the last
continue). All the last continue does is take them back to the Merchant
Invoice screen.

Weiland has a basket "viewer" module that will let you locate the contents
of that order so you can fulfill it. We are experimenting with a module that
will actually post the order to merchant order system after a failure, but
its still in alpha testing, and it can't be done reliabily, then there is
not point in releasing it.

With Viking and Weillan modules, I believe the that the Paypal response has
to fail twice before not commiting the order...but its happening with
greater frequency. We haven't tested the standard Miva Paypal module as yet.

-Bruce Golub
PHOSPHOR Media
www.phosphormedia.com

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Chuck
> Lasker - DoublePlus
> Sent: Monday, March 21, 2005 8:37 PM
> To: [email protected]
> Subject: RE: [mru] Paypal Payment but No Order Recorded
>
> They didn't click on the Continue button at the end of
> process, where it takes them from the PayPal site back to
> your site. A very common problem.
> You can instruct your users to "BE SURE TO CLICK THE FINAL
> CONTINUE BUTTON TO RETURN TO THIS SITE. YOUR ORDER IS NOT
> COMPLETE UNTIL YOU ARE RETURNED TO THIS SITE." Or, you can
> take the burden off your customers with one of these modules,
> which will get you the order data even if they don't click
> that last Continue button:
>
> <A HREF ="http://www.mivacentral.com/doubleplus/?product=VCS-BROK_PAYPAL">http://www.mivacentral.com/doubleplus/?product=VCS-BROK_PAYPAL</A>
>
> <A HREF ="http://www.mivacentral.com/doubleplus/?product=WCW-PAYPAL">http://www.mivacentral.com/doubleplus/?product=WCW-PAYPAL</A>
>
> Chuck
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]
> On Behalf Of Creative Crafts and Stickers (Jen Walker)
> Sent: Monday, March 21, 2005 11:04 PM
> To: [email protected]
> Subject: [mru] Paypal Payment but No Order Recorded
>
> I received two orders today where I received the paypal
> payment confirmation, but I did not receive an order
> confirmation and one was not
> recorded in the admin. I have read that this is a common
> problem. I am
> wondering what exactly my customers need to do in order for
> this not to happen. I am hoping to put some instructional
> words into the footers, but I need to know what they have
> done wrong before I can help them out. Any ideas? Thanks.
>
>

Paypal Payment but No Order Recorded



Are you using miva's paypal module? If so, checkout viking and weiland
instead
http://jmhonline.net/miva-modules/paypal

Also, weiland has lost and found orders which might help the current
situation.
http://jmhonline.net/miva-modules/lost+and+found

Jason


I received two orders today where I received the paypal payment
confirmation, but I did not receive an order confirmation and one was not
recorded in the admin. I have read that this is a common problem. I am
wondering what exactly my customers need to do in order for this not to
happen. I am hoping to put some instructional words into the footers, but I
need to know what they have done wrong before I can help them out. Any
ideas? Thanks.

Paypal Payment but No Order Recorded



Yes, I can confirm the suspicion. I've been investigating this behaviour too
because my fulfilment modules were blocked in a customer's store using the
PayPal module. I analyzed very detailed data pulled from the server during
the checkout and can with absolute certainty confirm that the checkout is
being interrupted just a fraction of a second after being launched - either
due to a design flaw at PayPal, or due to resource limitations on the
Merchant server. See more details further below.

As for the failed orders - you can use Ultra Batch to view them and convert
them into printable invoices and packing lists, or export them in all those
formats available in UB. This is a standard feature of Ultra Batch since
years, but somehow people are not aware of it and I rarely hear about
someone using it. It works even in the free version of Ultra Batch too.

<A HREF ="http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMUBAT">http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMUBAT</A>

You can also use MmTICKER to alert you by email automatically whenever the
number of failed orders reaches a specified threshold:

<A HREF ="http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMTICKER ">http://www.mivacentral.com/truxoft/?...UXOFT-MMTICKER </A>



If you are interested in the details of the PayPal problem, here you go:

I analyzed a store with Bill's PayPal module, but it will be the very same
case with any other PayPal module using the automated direct return. Unlike
the original Miva's PayPal module, these payment modules use automated CGI
call from PayPal's server back to Merchant should have brought improvement
and avoid lost orders when customers forgot to return back from PayPal to
Merchant by clicking the Continue button. Unfortunately, due to an incorrect
behaviour of the feature or due to server limitations, the effect is exactly
opposite:

When the payment is completed at PayPal, their server automatically calls
your Miva Merchant and starts the final checkout process launching all
fulfilment processes (email notifications, closing the basket, releasing
inventory, filing the order,...). This is an automated process, launched
from the PayPal server, not from customer's browser as usually. The customer
can, but does not need to click the Continue button. If he does, it starts
another concurrent process by redirecting him back to the store, but this
process does not perform any fulfilment tasks - it only displays the
invoice.

Unfortunately, PayPal's server only launches the checkout process, and
possibly it closes the connection to the Merchant server without waiting
till the process completes. It is the normal and designed Miva Empresa's
behaviour that when the remote peer closes the connection, it completes only
the current "atomic" task (typically an I/O operation, or a basic Miva
Script command) and halts without any error message. On the server I
analyzed, it took 600ms before the start of the process and the halt. Of
course, this time is rather short and the probability that the fulfilment is
not completed is very high. At slow servers, or stores with complicated
fulfilment, the probability of failure grows with the time needed for the
checkout.

It gets even worse when the customer clicks the Continue button at PayPal
immediately (or very quickly) after the payment - it has the effect that
both processes (the automated fulfilment process started from PayPal server,
and the manual process displaying the invoice) run concurrently with just
50% speed. Hence the probability of a premature interruption of the
fulfilment is practically doubled.

The other possibility for the interruption, beside the closed connection, is
some kind of process limitation on the server that would kill the first
process when the second one is started. This is the case at low-cost hosts
limiting the CPU/Memory artificially. See more details at:
http://miva.truxoft.com/mmfaq.htm#Q002

People experiencing this problem should first contact their host and make
sure any such limitations are removed. You can verify if your host applies
these limitations by launching several concurrent windows with Merchant
pages (i.e. several searches and packing in the same time). More reliable
testing can be done in MmDIAG (the Diagnose tab of Ultra Batch (Xadmin)) -
by hitting the Stress Test button.

<A HREF ="http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMDIAG">http://www.mivacentral.com/truxoft/?product=TRUXOFT-MMDIAG</A>

If it does not help and it proves the interrupted connection is the culprit,
PayPal module developers and users should contact PayPal and ask them to fix
the CGI call so that it keeps the connection open till the process finishes,
and/or that it parses the response and checks for HTTP errors (i.e. 500,
3xx, 4xx). In case it sees such error, it should communicate it to the
system - either though the API or by email to the owner.

Another possibility, besides removing the resource limitations, is trying to
change the Apache settings - trimming the KeepAlive directive or other
related parameters could possibly help to keep Empresa running longer after
the connection is closed.

Yet another possibility is avoiding the automated return from PayPal
altogether and using only the old manual return as it was at the original
Miva PayPal module. Of course, you then have to display a well visible
warning on your site to assure people really click the Continue button at
PayPal after completing the payment.


Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules






-----Original Message-----
From: Bruce Golub - Phosphormedia.com


That is what I thought for years, however, recent investigations show that
this is not the case, at least with Viking and Weiland's modules as they
post back when payment is committed in paypal (the screen before the last
continue). All the last continue does is take them back to the Merchant
Invoice screen.

Weiland has a basket "viewer" module that will let you locate the contents
of that order so you can fulfill it. We are experimenting with a module that
will actually post the order to merchant order system after a failure, but
its still in alpha testing, and it can't be done reliabily, then there is
not point in releasing it.

With Viking and Weillan modules, I believe the that the Paypal response has
to fail twice before not commiting the order...but its happening with
greater frequency. We haven't tested the standard Miva Paypal module as yet.

-Bruce Golub
PHOSPHOR Media
www.phosphormedia.com

> -----Original Message-----
> From: Chuck
>
> They didn't click on the Continue button at the end of
> process, where it takes them from the PayPal site back to
> your site. A very common problem.
> You can instruct your users to "BE SURE TO CLICK THE FINAL
> CONTINUE BUTTON TO RETURN TO THIS SITE. YOUR ORDER IS NOT
> COMPLETE UNTIL YOU ARE RETURNED TO THIS SITE." Or, you can
> take the burden off your customers with one of these modules,
> which will get you the order data even if they don't click
> that last Continue button:
>
> <A HREF ="http://www.mivacentral.com/doubleplus/?product=VCS-BROK_PAYPAL">http://www.mivacentral.com/doubleplus/?product=VCS-BROK_PAYPAL</A>
>
> <A HREF ="http://www.mivacentral.com/doubleplus/?product=WCW-PAYPAL">http://www.mivacentral.com/doubleplus/?product=WCW-PAYPAL</A>
>
> Chuck
>
> -----Original Message-----
> From: Creative Crafts and Stickers (Jen Walker)
>
> I received two orders today where I received the paypal
> payment confirmation, but I did not receive an order
> confirmation and one was not
> recorded in the admin. I have read that this is a common
> problem. I am
> wondering what exactly my customers need to do in order for
> this not to happen. I am hoping to put some instructional
> words into the footers, but I need to know what they have
> done wrong before I can help them out. Any ideas? Thanks.
>

Paypal Payment but No Order Recorded



Ivo Truxa wrote:
> When the payment is completed at PayPal, their server automatically calls
> your Miva Merchant and starts the final checkout process launching all
> fulfilment processes (email notifications, closing the basket, releasing
> inventory, filing the order,...). This is an automated process, launched
> from the PayPal server, not from customer's browser as usually. The customer
> can, but does not need to click the Continue button. If he does, it starts
> another concurrent process by redirecting him back to the store, but this
> process does not perform any fulfilment tasks - it only displays the
> invoice.

Your analysis does not explain this person's problem whatsoever. This
is about order not in admin. The very first process that occurs when
paypal.com posts the IPN back to merchant is to convert the basket to an
order and switch the basketlist flag for order_proc from false to true.
No emails are run or any other fulfillment modules at this point. The
order WILL DEFINITELY show in the store's admin with this first action.

Now the problem you are referring to is the inventory is not getting
adjusted and items are put back into inventory because the basket still
exists. It is not deleted, rather only the order_proc flag has been
changed from false to true. When expired baskets are deleted, the
inventory will be put back in stock if because of a design flaw in miva
corp's db.mv. When they changed the order create from basket function
between 4.16 and 4.18 merchant, they did not change the delete expired
baskets routine. They are still checking delete status rather than the
order_proc flag. If they changed it to only return inventory when the
order_proc flag is false, there would not be an issue with inventory
being returned to stock. PERIOD. You don't need to make any more out
of it than it is.

As for fulfillment modules running, they have absolutely no effect on
whether the order shows in admin or not. That step was made BEFORE the
fulfillment modules run. You can then explain why not all of them run
by your analysis of logs. Slow server, error in module's convoluted
code, mvcall or http out to a server that is unavailable, error in the
invoice template screen re: basket deletion, or many other issues. I
have seen all of them. This issue occurs whether they are using paypal,
check or many other payment modules. It is NOT (repeat NOT) limited to
paypal. It is dependant on the fulfillment modules that are running and
code in the INVC screen. MANY, MANY different scenarios have been
observed.

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

Paypal Payment but No Order Recorded



Creative Crafts and Stickers (Jen Walker) wrote:
>
> I received two orders today where I received the paypal payment confirmation, but I did not receive an order confirmation and one was not recorded in the admin. I have read that this is a common problem. I am wondering what exactly my customers need to do in order for this not to happen. I am hoping to put some instructional words into the footers, but I need to know what they have done wrong before I can help them out. Any ideas? Thanks.

It is likely that you are using the built in miva corp paypal module.
With that module, the customer has to click the final continue at
paypal.com so that the order will be completed.

If you are using one of the 3rd party paypal modules, it would be
because the paypal.com IPN server is down and did not post back to
merchant.

If you have never received a paypal order in admin, then it is probably
because the module is not setup correctly (this applies to both the
built in and 3rd party paypal modules).

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

Paypal Payment but No Order Recorded



I agree that if Miva changed the way it handles the inventory at checkout,
it would help to avoid the specific inventory problem.

However, the problem with PayPal method cannot be compared to other payment
methods. At all those standard payment modules, the checkout and fulfilment
processes have by default 90 secs time for the task (usually even more).
When using PayPal IPN, the process is interrupted within _milliseconds_.

It is true that the basket is converted into order as one of the first
things done after the return, but it does not mean it cannot fail due to the
short time too - it all depends on many factors - the speed of the server,
Apache settings, network speed, concurrent processes, additional tasks
during the checkout (such as logging), etc. Although the probability of the
process interruption before filing the order is lower than that it fails
afterwards, the time available for the process due to the IPN flaw (or
possibly due to server restrictions) is _extremely_ short. It remains
definitely a serious problem, and beside the messed up inventory, unsent
notifications, uncompleted fulfilment tasks, this awkward interrupting of
the fulfilment can also cause database corruption and other problems.

Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules



-----Original Message-----
From: William Weiland


Ivo Truxa wrote:
> When the payment is completed at PayPal, their server automatically calls
> your Miva Merchant and starts the final checkout process launching all
> fulfilment processes (email notifications, closing the basket, releasing
> inventory, filing the order,...). This is an automated process, launched
> from the PayPal server, not from customer's browser as usually. The
customer
> can, but does not need to click the Continue button. If he does, it starts
> another concurrent process by redirecting him back to the store, but this
> process does not perform any fulfilment tasks - it only displays the
> invoice.

Your analysis does not explain this person's problem whatsoever. This
is about order not in admin. The very first process that occurs when
paypal.com posts the IPN back to merchant is to convert the basket to an
order and switch the basketlist flag for order_proc from false to true.
No emails are run or any other fulfillment modules at this point. The
order WILL DEFINITELY show in the store's admin with this first action.

Now the problem you are referring to is the inventory is not getting
adjusted and items are put back into inventory because the basket still
exists. It is not deleted, rather only the order_proc flag has been
changed from false to true. When expired baskets are deleted, the
inventory will be put back in stock if because of a design flaw in miva
corp's db.mv. When they changed the order create from basket function
between 4.16 and 4.18 merchant, they did not change the delete expired
baskets routine. They are still checking delete status rather than the
order_proc flag. If they changed it to only return inventory when the
order_proc flag is false, there would not be an issue with inventory
being returned to stock. PERIOD. You don't need to make any more out
of it than it is.

As for fulfillment modules running, they have absolutely no effect on
whether the order shows in admin or not. That step was made BEFORE the
fulfillment modules run. You can then explain why not all of them run
by your analysis of logs. Slow server, error in module's convoluted
code, mvcall or http out to a server that is unavailable, error in the
invoice template screen re: basket deletion, or many other issues. I
have seen all of them. This issue occurs whether they are using paypal,
check or many other payment modules. It is NOT (repeat NOT) limited to
paypal. It is dependant on the fulfillment modules that are running and
code in the INVC screen. MANY, MANY different scenarios have been
observed.

Paypal Payment but No Order Recorded



Ivo Truxa wrote:
> Although the probability of the
> process interruption before filing the order is lower than that it fails
> afterwards, the time available for the process due to the IPN flaw (or
> possibly due to server restrictions) is _extremely_ short. It remains
> definitely a serious problem, and beside the messed up inventory, unsent
> notifications, uncompleted fulfilment tasks, this awkward interrupting of
> the fulfilment can also cause database corruption and other problems.

If the paypal.com IPN fails, it retries. So you get a couple shots at
converting the order_proc flag from false to true. In the cases of
inventory mess up that I studied, the order_proc flag was true (meaning
it did convert basket to order and the order shows in admin), but the
basketlist record was not deleted. The baskets records were not deleted
either.

In some cases, parts of fulfillment completed. These usually halted
with the emails.

In some cases, all fulfillment completed. These usually had something
in the INVC that was not standard (template, link to a hit tracker (eg
google), extra info using tokens, etc.

These failures were found with check, paypal, authorize.net, simple
validation. The failures had something to do with failure of
fulfillment modules running or invoice screen display. The most serious
problem is the inventory adjustment. A simple one or two line fix by
Miva Corp in the db.mv would eliminate this problem. I agree, that some
fulfillment processes might not complete, eg record an order in a
parallel order history module or not all of the emails being sent. But
that is not specific to paypal.com. If a database lookup in one of the
fulfillment modules goes into an infinite loop for some reason or an
email problem occurs, the whole process may timeout. It is not related
to a specific payment processor. It may be more prevalent in one over
the other, but it occurs in all of them.

It is the design of Merchant to stop if one of the fulfillment module's
fails. Wouldn't it be great if each fulfillment module would be
allocated 30 seconds to either complete or fail. After completion,
failure or 30 seconds, it would be closed and the timer would be reset.
No timeouts would be encountered, even if it took 10 minutes to run all
the fulfillment modules.

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

Question about WebNet Hosting



You do have weights assigned to your products? I know it can cause a problem
if you do not.
Jim

----- Original Message -----
From: "Melvin Webb" <[email protected]>
To: <[email protected]>
Sent: Tuesday, March 22, 2005 6:29 AM
Subject: [mru] Newbie. UPS Domestic Shipping, cant make it work


> Just started and want to see how the UPS domestic shipping calculator
> funtions. trouble is, even though I have configured it with either default
> or basic options, it never shows as an available shipping method.
>
> My tests are using proper addresses and zip codes, is there something else
> that needs to be set on the products or somewhere?
>
> Many thanks,
> Mel.
>

Question about WebNet Hosting



Hi, folks, long time no see.
(I've moved, and been busy developing
a new site-so I had unsubscribed for
a few months--not as if anyone would notice)

Could anyone contact me with stories good
and bad about WebNet Hosting? Specifically,
how good are they at understanding issues
with Miva? Do they set up Miva with security
in mind? Do they allow additional modules?

(I've done the regular thing of checking
archives for the subject and so on)

Thanks, and it's rather nice seeing all the
familiar names back in my Miva list folder.

Chris

Paypal Payment but No Order Recorded



Hi, folks, long time no see.
(I've moved, and been busy developing
a new site-so I had unsubscribed for
a few months--not as if anyone would notice)

Could anyone contact me with stories good
and bad about WebNet Hosting? Specifically,
how good are they at understanding issues
with Miva? Do they set up Miva with security
in mind? Do they allow additional modules?

(I've done the regular thing of checking
archives for the subject and so on)

Thanks, and it's rather nice seeing all the
familiar names back in my Miva list folder.

Chris

Paypal Payment but No Order Recorded



Bill, you apparently did not see what I wrote - so once more briefly:

Normal checkout: 90 secs (usually more)
PayPal IPN: 600 ms (depending on the server and other circumstances,
it may be more or even less)

Hence, although the fulfilment can certainly timeout within the standard 90
secs too, it is _much_ more probable at the PayPal IPN method during the
600ms. Thus, it _is_ a PayPal specific problem.

In no way it means it is your fault. It is fault of the PayPal interface. It
is caused either by the improperly handled IPN call from PayPal server
(connection dropped just after receiving the HTTP header), or (less likely)
by the restricted resources on the Merchant server - but in that case it is
also a flawed design of the PayPal IPN method, since it does not parse they
response.

Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules



-----Original Message-----
From: William Weiland


Ivo Truxa wrote:
> Although the probability of the
> process interruption before filing the order is lower than that it fails
> afterwards, the time available for the process due to the IPN flaw (or
> possibly due to server restrictions) is _extremely_ short. It remains
> definitely a serious problem, and beside the messed up inventory, unsent
> notifications, uncompleted fulfilment tasks, this awkward interrupting of
> the fulfilment can also cause database corruption and other problems.

If the paypal.com IPN fails, it retries. So you get a couple shots at
converting the order_proc flag from false to true. In the cases of
inventory mess up that I studied, the order_proc flag was true (meaning
it did convert basket to order and the order shows in admin), but the
basketlist record was not deleted. The baskets records were not deleted
either.

In some cases, parts of fulfillment completed. These usually halted
with the emails.

In some cases, all fulfillment completed. These usually had something
in the INVC that was not standard (template, link to a hit tracker (eg
google), extra info using tokens, etc.

These failures were found with check, paypal, authorize.net, simple
validation. The failures had something to do with failure of
fulfillment modules running or invoice screen display. The most serious
problem is the inventory adjustment. A simple one or two line fix by
Miva Corp in the db.mv would eliminate this problem. I agree, that some
fulfillment processes might not complete, eg record an order in a
parallel order history module or not all of the emails being sent. But
that is not specific to paypal.com. If a database lookup in one of the
fulfillment modules goes into an infinite loop for some reason or an
email problem occurs, the whole process may timeout. It is not related
to a specific payment processor. It may be more prevalent in one over
the other, but it occurs in all of them.

It is the design of Merchant to stop if one of the fulfillment module's
fails. Wouldn't it be great if each fulfillment module would be
allocated 30 seconds to either complete or fail. After completion,
failure or 30 seconds, it would be closed and the timer would be reset.
No timeouts would be encountered, even if it took 10 minutes to run all
the fulfillment modules.

Paypal Payment but No Order Recorded



Ivo Truxa wrote:
> Bill, you apparently did not see what I wrote - so once more briefly:
>
> Normal checkout: 90 secs (usually more)
> PayPal IPN: 600 ms (depending on the server and other circumstances,
> it may be more or even less)
>
> Hence, although the fulfilment can certainly timeout within the standard 90
> secs too, it is _much_ more probable at the PayPal IPN method during the
> 600ms. Thus, it _is_ a PayPal specific problem.

You apparently did not read what I wrote either. If we really only have
600ms, it is likely failure would occur often. It does NOT. I have 6
fulfillment modules running in my store. All of them update databases
that an order has completed (order history status, coupon, tax
exemption, etc). One of them, Mail Manager, sends at least 4 emails on
every software order, 5 on some. My payments are through paypal.com 99%
of the time. I rarely get failures during fulfillment; about 1 in
1000. The problem in stores with an inventory issue is going to lie
with server slowness, email module used, error in token on invoice
screen, slow communication with hit tracker, poorly constructed INVC
template, and a hundred other issues. 600ms is not the problem or I
would see it too. None of the most recent 3 hosts I have had my store
on have had a problem with paypal payments processing orders in the
fulfillment portion. These cover the entire period that paypal IPN has
been available.

Now, back to the original subject: There have been occassional
paypal.com glitches where the IPN server was down and orders did not
post at all. That is another subject. But is closer to the original
poster's subject than your response which is related to what happens
AFTER the order is already recorded in admin. The problem with orders
appearing in admin is not related to the time the paypal.com server
devotes to its IPN posting. Rather it is:

1) Is the customer using Miva Corp supplied paypal module? If yes, did
the IPN even attempt to post? With the Miva Corp supplied module (I
don't know the defective versions), IPN posts if the customer clicks the
final continue. If they forget to continue, no IPN posts to update the
order.

2) With all paypal module, is the module and paypal.com setup
correctly?

A. If ANY paypal paid orders get recorded in admin, then the module and
paypal.com is setup correctly. IPN server is probably having issues.

B. If the store is a new paypal module user and it has NEVER received a
completed paypal paid order in admin, the module or paypal.com is not
setup correctly.

It is just that simple. There is no need to do a major study of
processing times and actions of fulfillment modules to determine why an
order does not show in admin.

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

Paypal?



------=_NextPart_000_001F_01C52EC0.C4DDDCC0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi,



Can I use paypal for credit card purchases? Does it handle merchant accnt
and gateway services?



Pascal Dorion

Antigua Furniture Guild

<<A HREF ="http://www.afgperu.com> www.afgperu.com">http://www.afgperu.com> www.afgperu.com</A>




------=_NextPart_000_001F_01C52EC0.C4DDDCC0--