Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

NEW PAYPAL


RAGE

Recommended Posts

As of Friday, Feb 13 2004, PayPal now accepts credit card payments from non-members. This new feature, will be automatically activated on Premier and Business account holders and they may start taking Credit Card Payments from buyers using the existing PayPal contribution with no modifications needed.

 

Until now, PayPal has required that buyers open a PayPal account to send funds, and that their credit card number be kept on file, the new system has no such requirements.

 

I've dealt with the hassles of Authorize.net, Humbolt bank and Linkpoint for years, the high monthly charges, the chargebacks that are so easily obtainable thru fraudulent buyers, and the fact that you have to have a commercial bank account which has large opening deposits. them days are over....

 

[EDIT HPDL:] Some postings in this thread have been removed as they were offtopic.

Edited by hpdl
Link to comment
Share on other sites

  • Replies 61
  • Created
  • Last Reply

Top Posters In This Topic

I haven't been able to verify the above, but I have seen new features available

A more interesting bit of info is that PayPal now allows you to configure your PayPal profile so that the customer is immediately returned to the shoppingcart website once they click the pay button.

Also via the account profile you are able to customize the PayPal pages alot more, i.e specific background colors etc... See PayPal for more info.

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

Heres an email that i just got from PayPal, according to PayPal the new CC system isnt scheduled to be announced as of yet, although it is already implimented in the suite of new features listed below:

 

 

 

PayPal has optimized the checkout experience by

launching an exciting new improvement to its payment flow. These

changes apply to the following Website Payments features: Buy Now

Buttons, Donations, and PayPal Shopping Cart.

 

With the new checkout, making a transaction is

easier than ever. Your buyer can complete a payment first, and then

have the option of saving their information for future transactions.

Once customers have decided to make a purchase, they are walked

through four easy steps:

 

1. Shipping information

 

2. Billing information

 

3. Review of payment information

 

4. Save customer information with PayPal (optional)

? To shop more quickly and easily in the future, customers can

save their personal information they?ve already entered with

PayPal. All they need to do is choose a confidential password

and answer a few security questions.

 

To toggle off this new feature, simply log in, go to

Profile subtab, click on Website Payment Preferences in the

Selling Preferences column, and check the yes/no box under

PayPal Account Optional.

 

Sincerely,

 

The PayPal Team

Link to comment
Share on other sites

Netscape Screenshot:

 

http://www.tricountysearch.com/paypal.jpg

 

Test Link: (dont "really" check out, ok?)

 

http://www.tricountysearch.com/a.html

 

Please Note, if you have logged into a paypal account lately, the test link above will not show correctly unless you clear cookies, the second link should resemble the screenshot link listed first above.

 

But yep, it's there, operational, and confirmed

Link to comment
Share on other sites

That's correct: buyers no longer need to set up an account when paying through PayPal. This currently works for Buy Now (which OSCommerce and all of the contributions use) and Shopping Cart, but not Subscriptions. Unfortunately, our International team was busy with PayPal Germany and ELMI and so the feature does not yet work for non-US buyers. This is a top priority, however.

 

This modification applies primarily to buyers who have not used PayPal previously. The 40+ million existing PayPal users will not see much of a difference since they already have accounts.

 

We also rolled out some other features that merchants and developers have been requesting. Most notably, more ability to customize payment pages with color and graphics.

 

See http://paypal.typepad.com for more information.

 

We have lots of merchants who take PayPal exclusively (and have very successful businesses) and many who take PayPal along with other payment methods. We encourage that since our experience is that merchants who utilize multiple providers are very satisified with PayPal.

 

With respect to chargebacks, merchants typically see a lower rate for a variety of reasons (only about half of PayPal volume is through easily chargeback-able credit cards, chronic chargebackers may not use PayPal, considerably more resources to prevent and fight chargebacks). As one poster discovered, a dispute that PayPal denied was later accepted by the credit card company.

 

We would generally advise actually trying out PayPal to get the most accurate information on how it can help your business succeed.

Patrick Breitenbach

Link to comment
Share on other sites

It's possible (and encouraged!) to pass name, address and email information to PayPal so that buyers need not type it twice. https://www.paypal.com/cgi-bin/webscr?cmd=p...-signup-outside

 

Wizard, it looked to me like I would need to set up an account to buy one of your products. I'm pretty sure that's also how the core OSC system works (which is why the Purchase Without Account contrib exists).

 

We participate here because we believe OSC is one of the best options for setting up an online store and that many OSC businesses are using PayPal. We apologize for the commerciality.

 

There are a number of reasons why our flow is hosted, the two primary being 1) to password protect payments (giving us among the lowest fraud rates in the industry) and 2) selecting among multiple payment methods.

 

Most gateways offer a hosted option (AuthNet SIM, PayFlow Link) and Cybersource is *adding* one. We believe that with the amount of commerce being conducted through Amazon Marketplace, Yahoo Stores, eBay, PayPal and others that hosted interfaces are not only acceptable, but advantageous.

 

We'd very much like to work with the OSC team, Pablo and whoever to assist in providing the best PayPal/OSC integration possible.

Patrick Breitenbach

Link to comment
Share on other sites

We'd very much like to work with the OSC team, Pablo and whoever to assist in providing the best PayPal/OSC integration possible.

WOW! Don't miss that quote folks.......

 

Please take "Paypal" up on this offer........If this is your idea Patrick Breitenbach then tell "Paypal" I said to give you a raise for realizing the potential business that OSC can generate for Paypal....

 

God Bless...{whichever god, gods, goddess, goddesses, lack-of-god, or God you choose to worship or ignore}.... the best damn free shopping cart out there......OSC......you could probably even drop the "free" from that last sentence.....

 

********************************************************************

 

A couple of questions I guess.......

 

What made wizardsandwars turn so sour on paypal.....? Old posts circa 2002/3 show wizardsandwars paying paypal high praises......During this time what happened? Ignore this question if you feel I'm picking on anyone, but I'm not trying to.........

 

And....

 

I guess I could test it to see...but....

 

Does the current PAYPAL IPN OSC MODULE automatically fill in the paypal side order info from the osc customer account info or do we need to modify something to get it to fill in the fields automatically......?

 

Thanks for any replies......

 

Cheers!

Link to comment
Share on other sites

Hi,

We'd very much like to work with the OSC team, Pablo and whoever to assist in providing the best PayPal/OSC integration possible.

[...]

 

Does the current PAYPAL IPN OSC MODULE automatically fill in the paypal side order info from the osc customer account info or do we need to modify something to get it to fill in the fields automatically......?

 

Thanks for any replies......

 

Cheers!

 

I guess you are referring to the OSC built in PayPal module (i can't say anything about that one), but there is a fantastic (imho) new contribution that covers at least everything that i need. The name is PayPal_Shopping_Cart_IPN and the support thread is here. I am sure gregbaboolal (the author) is also following this thread.

 

Regards,

Marcus

Link to comment
Share on other sites

you should make a version of PayPal IPN that prepopulates the fields and does not require any changes to files other than the payment module (the current contribution requires changes to the checkout module)
This is possible with the current contribution, however in doing so osC would not be able to keep track of a payment transaction, it is merely there for the storeowners convience so that they can see the IPN transaction details in the admin. In doing so you also get to see the registration details that the customer has with PayPal which IMHO can help.

 

There are also others out there who want an enhanced order process to better handle pending payments and refunds.

 

but with virtual (downloadable) products, this can allow a malicious customer to get away without paying
The current contribution can detect this (and will email you to the fact) and if you wanted to be more stringent you could actually prevent the customer from checking out, but it was left as is because didn't want to steer too much away from the default osC scenario (otherwise more code/file changes - or a simple redirect - required).

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

In regard to the above comment of changing the checkout_process the PayPal_Shopping_Cart_IPN contrib only 'adds' one line of code to that file and does not change anything else, this is the transaction id number inserted with the rest of the info into the orders table.

 

Anyway, what I wanted to say further to Wizards point and what I think might be a possible solution is for the customer to have the choice to pay directly through PayPal, i.e they just click the checkout button and at the PayPal site it is there where they can view the cart items (Method 2) and enter shipping details.

 

via IPN, PayPal can also notify us of the shipping address. thus the transaction/order could be stored and the customer never needs to have to choose an account, either with the store or PayPal.

 

PayPal could even include a checkbox on their page to notfiy us whether the customer would like to create an osC account, similar to what I suppose happens at the end of the new CC method.

 

The point is that the shipping details are sent back via IPN, which I suspect would be even better if for example you wanted that address to be PayPal verfied.

 

I appreciate there needs to be some ironing out but it might be a way to go?

Edited by gregbaboolal

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

Yeah, I had time to think a little more and your right in that sense; however for some folk starting out etc, etc, merchant accounts are not an immediate option.

Then the other problem that might occur is supposing PayPal did start to offer offline processing, the customer then has to decide which PayPal method to use in the first place.

 

Oh well.

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

In regard to the above comment of changing the checkout_process the PayPal_Shopping_Cart_IPN contrib only 'adds' one line of code to that file and does not change anything else, this is the transaction id number inserted with the rest of the info into the orders table.
I think that the IPN module would be better suited to the current needs of people like wizardsandwars (who uses PayPal with other payment methods) if it was purely a drop in. To make it like this on the catalog side, one would simply not change checkout_process at all and change includes/modules/payment/paypal.php (around lines 132-4) from
    function after_process() {
     return false;
   }

to

    function after_process() {
     global $insert_id, $order;
     tep_db_query("update " . TABLE_ORDERS . " set paypal_ipn_id = '" . (int)$order->paypal_ipn_id . "' where orders_id = '" . (int)$insert_id . "'");
     return false;
   }

Ideally (IMO), one would get rid of even that much and just use the traditional osCommerce tables to store the PayPal info. More consistent interface that way. Also would simplify the admin part of the contribution.

 

You could then have a separate contribution which would do the post shipping checkout details on the PayPal side (or possibly even including shipping--difficult to operate complex shipping methods that way though). This would be for use of shops that only use the PayPal.

 

It seems to me that the current IPN contribution sort of straddles the two alternatives: too much to just be a drop in; not enough to be a replacement solution. YMMV.

 

My $.02,

Matt

Always back up before making changes.

Link to comment
Share on other sites

Although maybe misplaced, one might now consider the purpose of this thread as a discusion of further development of the PayPal module.

 

Matt, yes the $payment_module->after_process() is probably the best place for the ipn transaction id, but firstly I developed the code from scratch and through quite a bit of research and testing, throughout this time no one seemed to want to discuss the codes actual development, rather I pursued because I didn't have anything else to do and with feed back of osC users (PayPal's manual's give just enough to leave you guessing for the rest).

 

Anyway, even though there are other gateways etc that could be used, does not prevent us from developing upon PayPal's IPN initiative, personally I think in the advent of IPN people are/will want to utilize its functionality and this would require some significant changes/enhancements to osC preferably in a generic fashion, i.e a modular proccedure for invalid (3rd party?) payments.

 

Better handling of pending payments. Here it would also be nice for the customer to log back in and resume the checkout procress for that transaction (even after being edited by the storeowner - quotes etc...).

 

Yes, 'as is' the contribution might not be totally adequate, but as said in the readme notes, there is room for improvement. One particular reason for not wanting to go OTT with the prevention of checking out on a invalid payment (or even pending maybe) is that I thought it better to get a general concensus on these matters, which by the way I don't recall seeing any posts by you in the support thread - so you probably didn't have any problems with it (maybe) :D

 

One thing that wasn't clear to me was what Patrick(PayPal) would really expect to see for a recommendation of functionality between osC and Paypal.

 

I think if we could try to identify areas on how to utilize the PayPal IPN feature(s) etc would be a worthy area of development, auctionblox has already discussed wanting to enhance the order process to better suit his Ebay Auction Manager contrib, but all this should still occur under the osC umbrella and be preferably generic/modular to any payment method, it is just that PayPal's IPN is the first (that I know) that offers such a notification service.

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

It's possible (and encouraged!) to pass name, address and email information to PayPal so that buyers need not type it twice. https://www.paypal.com/cgi-bin/webscr?cmd=p...-signup-outside

 

This Paypal mod is listed under their Auction Tools, does anyone know how or where it could be incorporated into OSC so that customers only have to fill their details in once !

 

If it can be combined with Paypals Auto Return mod, it would seem to resolve a lot of the complaints about Paypal. If I can incorporate both, I would still want to use payment options.

 

Any suggestions ?

 

Thanks for any help :)

Link to comment
Share on other sites

It looks to me like changing the process_button function in includes/modules/payment/paypal.php to look like the following would work:

    function process_button() {
     global $order, $currencies, $currency, $customer_id, $billto;

     if (MODULE_PAYMENT_PAYPAL_CURRENCY == 'Selected Currency') {
       $my_currency = $currency;
     } else {
       $my_currency = substr(MODULE_PAYMENT_PAYPAL_CURRENCY, 5);
     }
     if (!in_array($my_currency, array('CAD', 'EUR', 'GBP', 'JPY', 'USD'))) {
       $my_currency = 'USD';
     }
     
     $billing_info_query = tep_db_query("select ab.entry_firstname, ab.entry_lastname, ab.entry_street_address, ab.entry_suburb, ab.entry_postcode, ab.entry_city, co.countries_iso_code_2, z.zone_code, c.customers_email, c.customers_telephone from " . TABLE_ADDRESS_BOOK . " ab, " . TABLE_COUNTRIES . " co, " . TABLE_ZONES . " z, " . TABLE_CUSTOMERS . " c where ab.address_book_id = '" . (int)$billto . "' and ab.customers_id = '" . (int)$customer_id . "' and ab.entry_country_id = co.countries_id and ab.entry_zone_id = z.zones_id and c.customers_id = '" . (int)$customer_id . "'");
     $billing_info = tep_db_fetch_array($billing_info_query);

     $telephone = preg_replace('/\D/', '', $billing_info['customers_telephone']);
     
     $process_button_string = tep_draw_hidden_field('cmd', '_ext-enter') .
                              tep_draw_hidden_field('redirect_cmd', '_xclick') .
                              tep_draw_hidden_field('business', MODULE_PAYMENT_PAYPAL_ID) .
                              tep_draw_hidden_field('item_name', STORE_NAME) .
                              tep_draw_hidden_field('amount', number_format(($order->info['total'] - $order->info['shipping_cost']) * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency))) .
                              tep_draw_hidden_field('shipping', number_format($order->info['shipping_cost'] * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency))) .
                              tep_draw_hidden_field('currency_code', $my_currency) .
                              tep_draw_hidden_field('first_name', $billing_info['entry_firstname']) .
                              tep_draw_hidden_field('last_name', $billing_info['entry_lastname']) .
                              tep_draw_hidden_field('address1', $billing_info['entry_street_address']) .
                              tep_draw_hidden_field('address2', $billing_info['entry_suburb']) .
                              tep_draw_hidden_field('city', $billing_info['entry_city']) .
                              tep_draw_hidden_field('state', $billing_info['zone_code']) .
                              tep_draw_hidden_field('zip', $billing_info['entry_postcode']) .
                              tep_draw_hidden_field('lc', $billing_info['countries_iso_code_2']) .
                              tep_draw_hidden_field('email', $billing_info['customers_email_address']) .
                              tep_draw_hidden_field('night_phone_a', substr($telephone, 0, 3));
                              tep_draw_hidden_field('night_phone_b', substr($telephone, 3, 3));
                              tep_draw_hidden_field('night_phone_c', substr($telephone, 6, 4));
                              tep_draw_hidden_field('day_phone_a', substr($telephone, 0, 3));
                              tep_draw_hidden_field('day_phone_b', substr($telephone, 3, 3));
                              tep_draw_hidden_field('day_phone_c', substr($telephone, 6, 4));
                              tep_draw_hidden_field('return', tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL')) .
                              tep_draw_hidden_field('cancel_return', tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));

     return $process_button_string;
   }

I haven't tested it though. Use at your own risk. You may want to leave off the telephone lines, as osCommerce doesn't have an exact equivalent to the PayPal choices.

 

Hth,

Matt

Always back up before making changes.

Link to comment
Share on other sites

One thing that wasn't clear to me was what Patrick(PayPal) would really expect to see for a recommendation of functionality between osC and Paypal.

 

Two main things:

 

1) An OSCommerce distribution that is highly tuned for PayPal (we get a zillion requests).

2) A solid PayPal module, ideally in the core distribution.

 

#1 is probably a lot of work so we can focus on #2.

 

High level requirements:

+ easy to activate PayPal and provide merchant ID (email address)

+ good integration into OSC checkout

+ pass name, address, country, email information to PayPal so shopper doesn't have to re-enter

+ OSC auto-magically specifies the return, cancel and notify URLs

+ usage of PayPal IPN to receive payment details and update OSC database

+ shopper returns to "Thank You" page after paying

+ proper handling of echeck payments which begin in a Pending state

 

Nice to haves:

+ multi-currency

+ pass image to PayPal for co-branding

+ adapt for digital goods

+ other?

Patrick Breitenbach

Link to comment
Share on other sites

Personally speaking, (not on behalf of the osC team or anybody else):

 

+ easy to activate PayPal and provide merchant ID (email address)

the PayPal_Shopping_Cart_IPN contribution follows the same (admin) installation principles as the original default osC paypal payment module, i.e the store owner clicks to install, and is prompted to enter their Primary PayPal email address and Business ID.

 

+ good integration into OSC checkout

IMO the original paypal does this already and when installed the PayPal_Shopping_Cart_IPN is a replacement for the original one so it works in the same fashion.

 

+ pass name, address, country, email information to PayPal so shopper doesn't have to re-enter

PayPal_Shopping_Cart_IPN supports this, with the current exception of telephone number and during development I saw a difference between the osC country codes and PayPal 'lc' codes for the following:

Anguilla[AI], Dominican Republic[DO], and The Netherlands[NL] have different codes to the iso codes in the osC db

+ OSC auto-magically specifies the return, cancel and notify URLs

the original paypal module does this (except for the 'notfiy_url' parameter) and so too does the PayPal_Shopping_Cart_IPN and I have recently posted in the support thread now that the 'notify_url' should be auto-magically included, it wasn't included in the original PayPal_Shopping_Cart_IPN contrib development since it previously was not an absolute PayPal requirement.

 

+ usage of PayPal IPN to receive payment details and update OSC database

PayPal_Shopping_Cart_IPN relates all of the essential information in each order page in the admin section, currently based upon v1.5 notify_version. There is also a seperate listing of the IPN's received and each links to it's corresponding order.

 

It would help if PayPal could list all of the IPN parameters available, their meaning and a webpage where we can view this for updates etc..

 

+ shopper returns to "Thank You" page after paying

This happens anyway, but better handling should occur for when a payment is still pending or not verified.

 

Patrick what is your response rate, have you had people reporting that their customers IPN could not be verified when they returned to the site, this might be considered prudent for downloads etc...

 

+ proper handling of echeck payments which begin in a Pending state

This still needs to be done, are test transactions available?

 

Nice to haves:

+ multi-currency

Altough I haven't tested it, this is already handled in the original osC paypal module, for the currencies allowed by paypal, so the PayPal_Shopping_Cart_IPN should also be doing this because it is an extension of the original osC paypal module. However storeowners have reported problems with verifying the values of the cart total (gross_mc), the currency (mc_currency), and number of items in the cart (num_cart_items), this can/should be ironed out - but how to isolate when the problem is occuring has been difficult, during development it seemed ok.

 

+ pass image to PayPal for co-branding

PayPal_Shopping_Cart_IPN allows the store owner to specify the image to be used on the PayPal site, however this is only suggested if the shopping cart website has SSL.

 

They can also choose the background color, currently black or white,

[A] do you know how many people choose black as their backgorunds,

When will you be allowing us to specify other colors.

 

+ adapt for digital goods

If refering to downloads, then clearly the customers IPN should be verfied and the payment status checked upon their return to the site.

 

With the feeback received since v1.5 of PayPal_Shopping_Cart_IPN there a some revision updates that should be included. And possibly further developed.

 

But there are probably further improvements that could be made; it was my first attempt in seriously working with osC and so each step was an osC and PayPal learning curve, neither of which have great manuals.

 

Normally I classify the two independent IPN's sent as:

[1] PayPal - osC - the one sent to the 'notify_url'

[2] Customer - osC - the one included with the customer when they return to the site

 

Also, the PayPal_Shopping_Cart_IPN contrib needs to be able to work with the admin/configrautions/sessions preferences, since the contrib was only designed based upon the default settings of a fresh osC instal, these being:

 

Force Cookie Use

Check SSL Session ID

Check User Agent

Check IP Address

Prevent Spider Sessions

Recreate Session

 

But this is really only for the PayPal - osC IPN and can be easily worked around in application_top.php

 

Further thought or clarification is required to handling refunds, especially since the change in PayPal methodology.

 

Where do we go from here?

Edited by gregbaboolal

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

Hi again Matt,

 

I had a chance to play and the coding worked perfectly except for a couple of typing errors. Once I corrected them there were no problems.

 

This is the corrected code.

 

function process_button() {

global $order, $currencies, $currency, $customer_id, $billto;

 

if (MODULE_PAYMENT_PAYPAL_CURRENCY == 'Selected Currency') {

$my_currency = $currency;

} else {

$my_currency = substr(MODULE_PAYMENT_PAYPAL_CURRENCY, 5);

}

if (!in_array($my_currency, array('CAD', 'EUR', 'GBP', 'JPY', 'USD'))) {

$my_currency = 'USD';

}

 

$billing_info_query = tep_db_query

("select ab.entry_firstname, ab.entry_lastname, ab.entry_street_address, ab.entry_suburb, ab.entry_postcode, ab.entry_city, co.countries_iso_code_2, z.zone_code, c.customers_email_address, c.customers_telephone from " .

TABLE_ADDRESS_BOOK . " ab, " . TABLE_COUNTRIES . " co, " . TABLE_ZONES . " z, " . TABLE_CUSTOMERS . " c where ab.address_book_id = '" . (int)$billto . "' and ab.customers_id = '" . (int)$customer_id . "' and ab.entry_country_id =

co.countries_id and ab.entry_zone_id = z.zone_id and c.customers_id = '" . (int)$customer_id . "'");

$billing_info = tep_db_fetch_array($billing_info_query);

 

$telephone = preg_replace('/\D/', '', $billing_info['customers_telephone']);

 

$process_button_string = tep_draw_hidden_field('cmd', '_ext-enter') .

tep_draw_hidden_field('redirect_cmd', '_xclick') .

tep_draw_hidden_field('business', MODULE_PAYMENT_PAYPAL_ID) .

tep_draw_hidden_field('item_name', STORE_NAME) .

tep_draw_hidden_field('amount', number_format(($order->info['total'] - $order->info['shipping_cost']) * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency))) .

tep_draw_hidden_field('shipping', number_format($order->info['shipping_cost'] * $currencies->get_value($my_currency), $currencies->get_decimal_places($my_currency))) .

tep_draw_hidden_field('currency_code', $my_currency) .

tep_draw_hidden_field('first_name', $billing_info['entry_firstname']) .

tep_draw_hidden_field('last_name', $billing_info['entry_lastname']) .

tep_draw_hidden_field('address1', $billing_info['entry_street_address']) .

tep_draw_hidden_field('address2', $billing_info['entry_suburb']) .

tep_draw_hidden_field('city', $billing_info['entry_city']) .

tep_draw_hidden_field('state', $billing_info['zone_code']) .

tep_draw_hidden_field('zip', $billing_info['entry_postcode']) .

tep_draw_hidden_field('lc', $billing_info['countries_iso_code_2']) .

tep_draw_hidden_field('email', $billing_info['customers_email_address']) .

tep_draw_hidden_field('night_phone_a', substr($telephone, 0, 3));

tep_draw_hidden_field('night_phone_b', substr($telephone, 3, 3));

tep_draw_hidden_field('night_phone_c', substr($telephone, 6, 4));

tep_draw_hidden_field('day_phone_a', substr($telephone, 0, 3));

tep_draw_hidden_field('day_phone_b', substr($telephone, 3, 3));

tep_draw_hidden_field('day_phone_c', substr($telephone, 6, 4));

tep_draw_hidden_field('return', tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL')) .

tep_draw_hidden_field('cancel_return', tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));

 

return $process_button_string;

}

 

It doesn't populate the telephone numbers, but they don't cause any problem.

 

I wondered if this is worth posting as a contribution as I know others were concerned about customers having to fill details in twice.

 

Thanks again

 

 

Vanessa

 

:P

Link to comment
Share on other sites

You actually don't need a separate query. This info is already available through the global var order, this is what I am doing:

 

 $process_button_string =
                                       tep_draw_hidden_field('cmd', '_xclick') .
                   tep_draw_hidden_field('business', MODULE_PAYMENT_PAYPAL_ID) .
                 // add unique id so Perl script can process IPN
                //   tep_draw_hidden_field('invoice', $order->customer['invoice']) .
                   tep_draw_hidden_field('item_name', STORE_NAME) .
                   tep_draw_hidden_field('shipping', '0') .
                   tep_draw_hidden_field('amount',
                                               number_format(($order->info['total'] -
                                               $order->info['shipping_cost']) *
                                               $currencies->get_value($my_currency),
                                               $currencies->get_decimal_places($my_currency))) .
                   tep_draw_hidden_field('shipping',
                                               number_format($order->info['shipping_cost'] *
                                               $currencies->get_value($my_currency),
                                               $currencies->get_decimal_places($my_currency))) .
                   tep_draw_hidden_field('currency_code', $my_currency) .
                   tep_draw_hidden_field('email', $order->customer['email_address']) .
                   tep_draw_hidden_field('first_name', $order->customer['firstname']) .
                   tep_draw_hidden_field('last_name', $order->customer['lastname']) .
                   tep_draw_hidden_field('address1', $order->customer['street_address']) .
                   tep_draw_hidden_field('city', $order->customer['city']) .
                   tep_draw_hidden_field('zip', $order->customer['postcode']) .
                   tep_draw_hidden_field('return', tep_href_link(FILENAME_CHECKOUT_PROCESS, '', 'SSL')) .
                   tep_draw_hidden_field('cancel_return', tep_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL'));

Edited by shughes

Shannon Hughes

Link to comment
Share on other sites

The new "Return" feature works great......

 

I just sent a test sale through and the customer NO LONGER HAS TO HIT THE FINAL CONTINUE BUTTON TO RETURN TO YOUR SITE.....

 

Worked like a charm......

The auto return will help the situation but I don't think it helps the situation where PayPal gives the user the chance to sign up in which case there still seems to be the possibility of not returning the customer to the OSC site.

 

I am currently working on a solution that uses a Perl script to handle the IPN updates. My main goal was to try and not touch too much OSC code. I just started working with OSC in the past couple weeks so I was unaware of the issue with the "continue payment" OSC issue until I really dived into the code last night. Looking forward to studying how this beast works.

 

One solution that has worked in the past with shopping cart technology is to create an orders/cart table that mimics a session based shopping cart. A column is dedicated to whether or not the user actually completed the shopping process, sometimes I have seen the user id set to -1, sometimes I have seen a status/unique ID combo. A cron job in the background runs every night and wipes out old order/shopping carts based on a specific age. I quicky glanced at Greg Baboolal's code and it looks like he is using a couple unique ID's that are in a race, which one wins determines whether the customer goes through the normal checkout script or whether the IPN code runs. Lots of ways to do this.....isn't that what makes this fun.

 

The key here is to create a unique "invoice" number BEFORE the customer is sent to PayPal so we have something to identify with. The invoice number would be used by the IPN script to update the necessary tables. That's the direction I am going to take. I will be happy to post what my solution is. Still in the requirements/design stage as I want to come up with a solution that does not touch much OSC code. Ideally it would also be easy for others to incorporate with out much programming knowledge. I was hoping all I would have to do is drop a cgi script on my web server (can't get more code separation than that) but it looks like I will need to modify some OSC code since the OSC order is not created until after the PayPal payment.

 

More later,

 

Shannon Hughes

Red Hat Web Engineer

Shannon Hughes

Link to comment
Share on other sites

Hi Shannon,

 

The 2 unique ids are the customer's session id and the paypal_txn id, at the time of development (2 weeks over Christmas) the Auto-Return feature was not available and since PayPal does not guarantee for the IPN to be sent 'immediately' , having the IPN information returned with the customer when they click the continue button also does cause the IPN script to be run, hence the race.

 

Creating a temporary orders table is probably the way to go, there is a contribution that already does this. There is, incidently, also a contribution makes use of abandon carts for further/better marketing.

"Any fool can know. The point is to understand." -- Albert Einstein

Link to comment
Share on other sites

Working it from both angles (IPN vs successful continue or auto return) like you have currently implemented reduces the chance for lost orders. If the IPN fails then chances are you have it covered with the normal checkout process.

 

After thinking about it some more I think I will not need temp tables. The two approaches I am currently pondering is one similar to yours or just completely bypassing the OSC checkout script and jump straight to the success on auto-return or successful continue button. For the latter I would leave it up to the Perl IPN script to duplicate the functionality of the checkout script in a cgi script. I would either create a unique ID or send the session ID as the invoice/custom number to PayPal.

 

Your approach has the advantage of covering both opportunities of receiving notifications (one from paypal success and one from the IPN). If the IPN messages have been known to not work 100% then this approach is very attractive.

 

Separating the logic out to Perl has the advantage of minimal code edits to the stock OSC. I don't know the ins and outs of OSC yet, but would assume this would be attractive when upgrading releases if table structure does not alter significantly. Currently I have another site, FVBC , that is wrapped around PHPBB...uses its session management, and many tables....I have not upgraded PHPBB because I have changed so much of the code that it would take a big effort to integrate into a new version. Hence my drive to separate my logic out with OSC...don't want to be in the same position.

 

You mentioned your IPN script is running also when someone clicks continue. Is PayPal sending you any post/get vars or are you using a session var to identify the customer with this scenario?

 

Shannon Hughes

Red Hat Web Engineer

Edited by shughes

Shannon Hughes

Link to comment
Share on other sites

You mentioned your IPN script is running also when someone clicks continue. Is PayPal sending you any post/get vars or are you using a session var to identify the customer with this scenario?

 

Shannon Hughes

Red Hat Web Engineer

When someone clicks "Continue", PayPal POSTs the transaction variables to the receiving page where the user goes after clicking Continue.

 

I usually use those to verify the transaction (again) and then prepare the file download.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...