Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

PayPal App for osCommerce Online Merchant


Recommended Posts

Comparing all the ...->_app->log(... calls in Frozen, it looks like ext/modules/payment/paypal/express.php on line 281 is missing a sixth parameter: ,(OSCOM_APP_PAYPAL_PS_STATUS == '1') ? 'live' : 'sandbox' . Is that the only fix needed, or are there more? Can someone with a PayPal setup try it out?

Link to comment
Share on other sites

  • Replies 293
  • Created
  • Last Reply
2 hours ago, MrPhil said:

Comparing all the ...->_app->log(... calls in Frozen, it looks like ext/modules/payment/paypal/express.php on line 281 is missing a sixth parameter: ,(OSCOM_APP_PAYPAL_PS_STATUS == '1') ? 'live' : 'sandbox' . Is that the only fix needed, or are there more? Can someone with a PayPal setup try it out?

would that not be EC for express rather than PS for standard?

No longer giving free advice. Please place deposit in meter slot provided.  Individual: [=] SME: [==] Corporation: [===]
If deposit does not fit one of the slots provided then you are asking too much! :P

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

In ext/modules/payment/paypal/express.php on line 281 I changed

$paypal_express->_app->log('EC', 'CallbackResponse', 1, $log_sane, $params);

to

$paypal_express->_app->log('EC', 'CallbackResponse', 1, $log_sane, $params, OSCOM_APP_PAYPAL_EC_STATUS);

This gave me the missing CallbackResponse in the PayPal log an got rid of the error messages in system logs

No longer giving free advice. Please place deposit in meter slot provided.  Individual: [=] SME: [==] Corporation: [===]
If deposit does not fit one of the slots provided then you are asking too much! :P

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

Couldn't edit my post

In ext/modules/payment/paypal/express.php on line 281 I changed

$paypal_express->_app->log('EC', 'CallbackResponse', 1, $log_sane, $params);

to

$paypal_express->_app->log('EC', 'CallbackResponse', 1, $log_sane, $params, (OSCOM_APP_PAYPAL_EC_STATUS == '1') ? 'live' : 'sandbox');

This gave me the missing CallbackResponse in the PayPal log an got rid of the error messages in system logs.

The 7th argument would be for IPN which could be set true but has default false.

I was able to edit this post

No longer giving free advice. Please place deposit in meter slot provided.  Individual: [=] SME: [==] Corporation: [===]
If deposit does not fit one of the slots provided then you are asking too much! :P

Is your Osc dated try Phoenix  raising oscommerce from the ashes.

Link to comment
Share on other sites

  • 1 month later...

Hello,

 

I need to locate the correct function in file that really confirms that the payment is confirmed.

 

/modules/payment/paypal_standard.php:

function verifyTransaction($pptx_params, $is_ipn = false) {

Is this enough? After the tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array); ?

 

Best regards

Link to comment
Share on other sites

1 hour ago, sinopia said:

Hello,

 

I need to locate the correct function in file that really confirms that the payment is confirmed.

 

/modules/payment/paypal_standard.php:

function verifyTransaction($pptx_params, $is_ipn = false) {

Is this enough? After the tep_db_perform(TABLE_ORDERS_STATUS_HISTORY, $sql_data_array); ?

 

Best regards

What do you actually want to achieve?

That method records that the payment has been verified, it doesn't do the verification.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

27 minutes ago, sinopia said:

Something like a callback, so when the paypal payment is confirmed, I send a cURL request with the invoice to my e-printer.

In that case, you could put it in that method and it will get run when the payment is confirmed.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

On 7/8/2019 at 3:11 PM, sinopia said:

@BrockleyJohn but which one?

if ( $result == 'VERIFIED' ) {

or

function verifyTransaction?

I think it's accessed twice from standard_ipn.php and paypal_standard..

Yes one is executed on receiving an IPN, the other in checkout_process if the customer comes back to the site. If you put it in the definition of function verifyTransaction it will always get executed.

If you only ever want it to get executed once, then you might have to do some extra work.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

  • 4 months later...

Hello. I've seeing this at error_log:

 

[10-Nov-2019 18:41:29 Europe/Lisbon] PHP Warning:  sizeof(): Parameter must be an array or an object that implements Countable in /home/x/public_html/includes/modules/mail_manager/order_confirm.php on line 17
[10-Nov-2019 18:41:29 Europe/Lisbon] PHP Warning:  session_destroy(): Trying to destroy uninitialized session in /home/x/public_html/includes/functions/sessions.php on line 162

I'm using the last app from paypal. This seems to happen in checkout_success.php while GET request from paypal.com/webapps... Checked at logs and it was at the same exact time.

Using PHP 7.3, I'm aware that sizeof could get some warning in PHP7.3 and saw that in some cases count() should be used.

Sometimes paypal recreate a new order id, I'm not sure if this happens in all osCommerce stores but in my case some paypal orders became +1 (order 1234 will become 1235 for example). 

Could it accessing the old order variable and as it doesn't exists cause this warning?

Best regards.

Link to comment
Share on other sites

By the way order_confirm.php is send mails using PHPMailer. The line 17 is:

  for ($i=0, $n=sizeof($order_totals); $i<$n; $i++) {

I've added this before because I weren't recognizing order variable:

// Fix for paypal_standard.php - $order_id and checkout_process.php uses $insert_id
if (strpos($order->info['payment_method'], 'PayPal') !== false) {
  $insert_id = $order_id;
}

Is someone has this issues or could know what can be causing this I would really appreciate any help.

 

Also what is going on with session_destroy()? Should the application_top.php create or recreate and application_bottom.php destroy? Line 162 is:

return session_destroy(); // from function tep_session_destroy() {

Best regards.

Link to comment
Share on other sites

9 minutes ago, sinopia said:

By the way order_confirm.php is send mails using PHPMailer. The line 17 is:


  for ($i=0, $n=sizeof($order_totals); $i<$n; $i++) {

I've added this before because I weren't recognizing order variable:


// Fix for paypal_standard.php - $order_id and checkout_process.php uses $insert_id
if (strpos($order->info['payment_method'], 'PayPal') !== false) {
  $insert_id = $order_id;
}

Is someone has this issues or could know what can be causing this I would really appreciate any help.

 

Also what is going on with session_destroy()? Should the application_top.php create or recreate and application_bottom.php destroy? Line 162 is:


return session_destroy(); // from function tep_session_destroy() {

Best regards.

Your mailer is failing to get order totals for the order - from which I guess it's failing to load the order at all, quite possibly because it's processing an invalid order id.

Paypal shouldn't be creating extra orders. An order in the preparing status is created before your customer leaves to pay in paypal. This order should be updated either by the returning customer or by paypal ipn whichever gets there first.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

On 11/11/2019 at 8:15 PM, BrockleyJohn said:

Paypal shouldn't be creating extra orders. An order in the preparing status is created before your customer leaves to pay in paypal. This order should be updated either by the returning customer or by paypal ipn whichever gets there first.

100% i agree.


This is a policy osCommerce prefer to proceed.
This not just justificate to Paypal............ many checkout systems count on it.
Stripe is also one of it.
I must be honest................. i see it ( and kind of works for the system).............. yet i also see it it is not right way.
It kind of work more like a plaster, instead cover the checkout process..
I agree.............. it isn't right.
It seems in most cases..................... just not in oscommerce it is covered decently.
Let say it................ it is doubt full.
 

No real blame........ just a notice.
 

Link to comment
Share on other sites

It is NOT right to see when MONITOR a checkout...................

In the ADMIN you SEE someone process the checkout.
And at a later point you see someone either PASS the checkout or FAIL the checkout.
It is TO obvious this PROCESS should be outof the monitoring process of oscommerce.
It holds an order ID to oscommerce DB.

Yeah.............. it tell you if succeed or not................ 100% agree.

But i think the goal is here to only give a %100 purchase.
Perhaps i am wrong in the understanding of the question, correct me if i am wrong.
 

Link to comment
Share on other sites

On 11/11/2019 at 8:15 PM, BrockleyJohn said:

Also what is going on with session_destroy()? Should the application_top.php create or recreate and application_bottom.php destroy? Line 162 is:


return session_destroy(); // from function tep_session_destroy() {

Best regards.

Is most checkouts not count on the payment gateway sequence?
IPN is where oscommerce most count on?
Not sure if that should be handled via application_top.php

It definitely would result in a "Headers already sent".
Curious about this handling.

Link to comment
Share on other sites

I agree 100% if this topic try to raise:
orders table, and while the order is processed, the shop get like 3 times a "update".And the update simply skip from order id 1 to order id 3.
When after look in the DB.............. you will not find an order ID 1 or 2.
Just 3.
I think this is not right.
but i might loose here the point! 

Link to comment
Share on other sites

I say here i might loose the point.........................
But i think this is exactly where all this conversation bounces to.

I might be wrong here.................
I might be right.
But i think it situates the issue.
Orders are go from 1 ( initial order)...............while processing.............. to order 3 in our DB

That is a strange behavior and prob is related to the initial question asked. ( and i think more prob's).

Link to comment
Share on other sites

Many of the payment modules, including paypal, create an order in the preparing state before leaving checkout. If the customer returns to the choose payment page, the preparing order is deleted and thus an order number is skipped.

You are right. No one sees that as a flaw.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

Yes, generally I believe the order number is created after the transaction is completed. However with PayPal it requires an order number to be generated prior to the transaction completion... As near as I can tell, and perhaps Ponce de Leon can weigh in here, but what you're seeing is entirely the result of dealing with PayPal. For instance, when using authorize.net, there is no order number transmitted to authorize.net. no actual order exists until the transaction is complete. At that time the customer basket becomes an order.  When you see the order number skipping, it is because the customer is changing the contents of his cart after reaching either the payment module and choosing PayPal or the final confirmation page.  In my case I have altered the code on the orders page not to show orders with the status assigned to PayPal pending orders. So my orders page only shows completed transactions, and there is always a gap in the numeric sequence.

Link to comment
Share on other sites

11 hours ago, Supertex said:

Yes, generally I believe the order number is created after the transaction is completed. However with PayPal it requires an order number to be generated prior to the transaction completion... As near as I can tell, and perhaps Ponce de Leon can weigh in here, but what you're seeing is entirely the result of dealing with PayPal. For instance, when using authorize.net, there is no order number transmitted to authorize.net. no actual order exists until the transaction is complete. At that time the customer basket becomes an order.  When you see the order number skipping, it is because the customer is changing the contents of his cart after reaching either the payment module and choosing PayPal or the final confirmation page.  In my case I have altered the code on the orders page not to show orders with the status assigned to PayPal pending orders. So my orders page only shows completed transactions, and there is always a gap in the numeric sequence.

For payment methods like cash on delivery, phone or bank transfer the order must also be created before you get the payment or you wouldn't know how much they were supposed to pay you or what to ship!

When the payment method involves routing the customer to another site for the process to be completed, there is the possiblity that they don't return even if they have paid. If you don't record the order before they leave, you may have no record of what they bought; you might just get an email from the payment provider that says Joe Soap paid you $57. Even if you have passed all the order info to the payment provider and it's included in the order information, you still have to type it all in again to record the order on your system if they don't come back.

Even if all of your customers always pay, your payment provider will always want to record an order reference against the payment processing. If you create the order when the customer comes back from paying, you don't know for sure what the order number is going to be. You can make an educated guess that it will be the next order number in the sequence but you can't be sure, if two customers are paying at around the same time, who will finish first. So you need to reserve the order number that's going to be used before the customer goes to pay (which is what happens when you create the order beforehand and will mean you get gaps in order numbers even if you don't create them first) or you have to invent a completely parallel alternative order reference number separate from the order number and not ending sequentially and make sure it's unique.

TL;DR if you don't want gaps in order references you have to invent another order reference scheme that doesn't have a sequential number on the end and use that instead of orders_id. Otherwise they are as unavoidable as death and taxes.

Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released.

Looking for a payment or shipping module? Maybe I've already done it.

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Link to comment
Share on other sites

26 minutes ago, BrockleyJohn said:

Otherwise they are as unavoidable as death and taxes.

😂

I have to agree with @BrockleyJohn  .. Actually I think an ordernumber should be created on chekcout_payment.php and order should be stored in DB immediately at checkout_process.php .. The need for it would probably depend on different Payment Service Providers / Gateways but in my experience the ones I have seen could be handled better with an existing/created ordernumber.

Actually this was one of the first changes we did some 15 years ago when we started to use oSC.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...