<p>Number of items in this order: {order_items:total_results} ({order_transaction_id})</p>
{/exp:weblog:entries}
{/if}
{/exp:cartthrob:submitted_order_info}
When using the PayPal Standard gateway, after the customer has paid and is returned to this order confirmation template, the first transaction ID variable
{transaction_id}
is always empty, while the second one in between the weblog:entries contains the proper transaction id.
PayPal Standard is a two step process: 1st) they redirect the user back to your site, 2nd) they ping your IPN url to tell the system that the transaction has processed. I believe that you can get redirected back to the site before the IPN goes through, and so at that point you wouldn’t have a transaction_id. I would say if you are having issues with the {transaction_id} tag, and the {order_transaction_id} tag works in your weblog:entries tag, you should go ahead and just use the weblog:entries tag to display your transaction_id.
{exp:cartthrob:submitted_order_info}
{if authorized}
<p>Your transaction is complete!</p> {exp:weblog:entries weblog="orders" entry_id="{order_id}" show_future_entries="yes" status="Completed"}
PayPal Standard is a two step process: 1st) they redirect the user back to your site, 2nd) they ping your IPN url to tell the system that the transaction has processed. I believe that you can get redirected back to the site before the IPN goes through, and so at that point you wouldn’t have a transaction_id.
Yes, this is indeed what I thought initially, but then it would not make sense that the {order_transaction_id} tag works (coming from an existing entry in the orders weblog, which means that the ping already came back from PayPal?), and {transaction_id} does not. Or am I missing something?
Yes, this is indeed what I thought initially, but then it would not make sense that the {order_transaction_id} tag works (coming from an existing entry in the orders weblog, which means that the ping already came back from PayPal?), and {transaction_id} does not. Or am I missing something?
Your {order_transaction_id} is data stored with the entry. Entry data is not polled to display the {transaction_id}. So it’s entirely possible that paypal could update via IPN immediately, and the {order_transaction_id} would be stored without the {transaction_id} being shown.
That said, I’ve reviewed how we expect paypal to return the {transaction_id} and I’ll do some testing to see if we’re actually getting that value back correctly.
Do you have any news on this issue? I am experiencing the same problem - {transaction_id} is not outputting anything. But the transaction id is being saved into the Orders weblog. Not always before arriving at the confirmation page, but within about 5 seconds to 2 minutes.
It looks like PayPal is sending the tx= parameter in the return URL but CT is not outputting the {transaction_id}.
Just an FYI, with my experience on PayPal’s IPN - when PayPal is having issues (sometimes these can be major issues when they roll out upgrades on their live site) their IPN notifications become backlogged for hours. I have seen delays of 12-14 hours on occasion.
Also, any thoughts on supporting Payment Data Transfer (PDT) from PayPal on the return URL? PDT is turned on in my SandBox account.
I’m having the same issue I think… {transaction_id} stopped outputting, but it is saved to the Orders weblog. I had it working for a while before then it stopped. I haven’t had a chance to chase it down yet because I have a bunch of other things to deal with. I’ll report back with I can find, if I can find anything.
The forum’s text parsing is screwing up the URL with semi colons. You can remove them.
I have recently fixed “{AID:Cartthrob:Apayment_return}” with Rob’s fix found here (for anyone else reading this, note Rob’s correction 2 posts down that thread - “gateway=”)
