Jump to content

pbreit

Members
  • Content count

    154
  • Joined

  • Last visited

Everything posted by pbreit

  1. pbreit

    PayPal Website Payments Pro - v0.1

    This is a support thread for the PayPal Website Payments Pro v0.1 contribution. Please log all bugs and feature requests here. The contribution is available at: http://www.oscommerce.com/community/contributions,3716
  2. pbreit

    PayPal Website Payments Pro - v0.1

    Sid, that's a great suggestion and I will look into that immediately.
  3. pbreit

    PayPal Website Payments Pro - v0.1

    Can you try setting the path to "paypal_wpp/certs/cert_key_pem.txt". Yes, you need to download a certificate from PayPal. Log in to your PayPal account and go to "Profile > API Access > Obtain API Certificate". Download a certificate and upload it to your web server over-writing the "cert_key_pem.txt" that already exists at "paypal_wpp/certs/". You might rename the existing cert_key_pem.txt so it doesn't go away.
  4. pbreit

    PayPal - A SOLUTION to Customer not returning to site.

    The contribution below implements the IPN notification service. It was developed by the OSCommerce core team. http://www.oscommerce.com/community/contributions,2679
  5. pbreit

    PayPal Website Payments Pro - v0.1

    A 10002 error indicates that the API Account Name, API Account Password and API Certificate aren't matching. Double check each of those. You might try re-downloading your API certificate. Make sure you are using your API password which is different from your regular PayPal account password. And make sure you are you are using the appropriate site, either the sandbox or the live site.
  6. pbreit

    PayPal Website Payments Pro - v0.1

    Setting the IPN there is optional. We will make that clear in the documentation. If you are a merchant and want IPN (see paypal.com/ipn) it's probably best to set up IPN in your PayPal Profile. We are still looking into the other issues users are seeing and hope to have information shortly.
  7. pbreit

    PayPal Website Payments Pro - v0.1

    Did you edit the path to the API Certificate File or is that what it defaulted to? Can you try setting it to: "paypal_wpp/certs/cert_key_pem.txt".
  8. pbreit

    PayPal Website Payments Pro - v0.1

    Is the mis-spelling of "category" just in your post or did you copy/paste that from your OSC admin?
  9. pbreit

    PayPal WPP Direct Payments & Express Checkout Support

    When testing Direct Payment on the sandbox, use a credit card number other than 4111111111111111.
  10. pbreit

    Official PayPal IPN Support Thread

    The double display of the "Total Amount" appears to be a bug. I've logged a bug on our side. Since it's a cosmetic bug, I don't think it will make it into an emergency fix so we may not see a fix for a week or two. I will work with the osC team to see if we can come up with a better way to handle addresses so that merchants can make sure they ship to an address they are comfortable with. Thanks for the feedback.
  11. pbreit

    [Contribution]Paypal IPN - Devosc

    Vger, there shouldn't have been any change in which page is displayed first on paypal.com (except that our recent wite upgrade may have referesehd cookies). I can have a look if you provide a link to your store.
  12. pbreit

    PayPal sign up optional now. Any new Modules?

    The new "sign up optional" flow will be used if your account has been activiated. You don't have to do anything to your osC integration to get it. If you are not seeing the new flow (check the upper right for "breadcrumbs" in the "not a PayPal user" branch), the best thing to do is contact customer service who will be able to turn it "on" for you.
  13. pbreit

    [Contribution]Paypal IPN - Devosc

    IPN retries until it is successful. Our server looks for a "2xx" response from your web server (e.g., "200 OK"). Make sure you aren't catching errors and returning a page wth a 200 response. 500 errors should be returned if you want the IPN server to retry.
  14. pbreit

    PayPal_Shopping_Cart_IPN

    If the setting is On in your account, buyers should be going through the optional sign up flow. It's not a situation where the shopping cart could turn it on or off. You should see this: https://www.paypal.com/xclick/business=ruby...ld.com&amount=1
  15. pbreit

    PayPal_Shopping_Cart_IPN

    Regarding https and cURL: Since PayPal does not require IPN transmissions to be "https" (no credit card information is being sent), it is OK to go with "http" in which case fsockopen can be used. It might be preferable to default to this since it is nearly universally supported whereas cURL and https are much less broadly supported.
  16. pbreit

    PayPal_Shopping_Cart_IPN

    This actually isn't required. The mere inclusion of the field "notify_url" in the PayPal button/form activates IPN. IPN was specifically designed for this situation so that merchants could use a cart solution like osCommerce without needing to do *any* configuring of their PayPal account.
  17. pbreit

    PayPal_Shopping_Cart_IPN

    This can be addressed reliably by the module. IPN includes two email fields: "receiver_email" which is the Primary email in the PayPal account. "business" which is an echo of the "business" field used in the PayPal button. In this situation, it is best to match "ipn.business" to "button.business".
  18. pbreit

    PayPal_Shopping_Cart_IPN

    Greg, that sounds great. I guess until osC implements the capability to store carts/orders prior to payment processing, that's what needs to be done. I'm really surprised that osC doesn't store unpaid carts since that information is so valuable to merchants. I think it's OK to wait for the payment before permanently decrementing inventory. I think the ideal is that inventory is temporarily decremented when added to a cart and then either permanently deleted upon payment or released back to the store shelf after a period of time. This isn't really a PayPal issue, tho. We're working on a sandbox which should become available next month. Until then, testing echeck IPN is difficult. Basically, the first echeck IPN and the second are nearly identical. The differences are: First IPN: payment_status=Pending, pending_reason=echeck Second IPN: payment_status=Completed The easiest approach is to disregard the first IPN. A second approach is to indicate that for a particular order, payment is pending via PayPal echeck. I'm not aware of a field named "image". Where did you see that? We have something called "page_style" which enables a merchant to specify different page customization screens. Probably best just to do nothing which will use the merchant's default page style.
  19. pbreit

    PayPal_Shopping_Cart_IPN

    We're investigating this. As you may have noticed, we recently added the ability to encrypt buttons created at our site. It's trickier to support this for "off-site" created buttons because of the "key" exchange. It is unlikely we will have this capability anytime soon. The key to preventing order-tampering is to check the data that is received through IPN: 1) that the IPN is authentic (when posted back to PayPal, a "VERIFIED" response is returned) 2) ipn.business = button.business 3) ipn.mc_gross = button.amount & ipn.mc_currency = button.currency_code 4) ipn.payment_status = Completed 5) ipn.txn_id has not been previously processed
  20. pbreit

    Paypal Module

    Note that inclusion of "return" in the PayPal button will over-ride the Auto-Return URL specified in the merchant's PayPal account Profile. I'd suggest holding off on those other features until the core payment functionality is perfected (primarily, the use of IPN exclusively for payment information transmission). Page style only needs to be specified if the merchant has multiple styles which is not too common. The image_url is a nice feature but, as noted, there can be issues if it is not hosted from an https location. Transmitting the cart details to PayPal is a nice feature but isn't strictly necessary in this situations since osC keeps track of the cart contents (the feature is provided for shopping cart systems that do not store the cart details).
  21. pbreit

    Core PayPal Support

    We like osCommerce and get a lot of inquiries about PayPal support in osCommerce. Likewise, there appears to be a lot of discussion regarding PayPal at the osC boards. We would like to offer our assistance in any way we can to ensure that osCommerce and PayPal users have the best support possible. One current issue is that there are currently at least 3 widely used PayPal modules: built in to osC 2.2, PayPal IPN and PayPal_Shopping_IPN. I think that PayPal is popular enough that it makes a lot of sense to include one really good module in the core distribution. Here are some of the things I think should be implemented: 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 + exclusive usage of PayPal Instant Payment Notification 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 + adapt for eBay Manager contribution + other? We are very anxious to assist so please let us know how we can do so. Thank you. pb (at) p*yp*l (dot) com
  22. pbreit

    PayPal_Shopping_Cart_IPN

    The above are suggestions based on experience, not stipulations. It is OK to combine the "rm=2" method but we typically recommend against it because it is unnecessary and can introduces a lot of room for error, especially with something as widely distributed as osCommerce. Developing the PayPal module ourselves is a difficult proposition both because we don't have the right php and osCommerce expertise and because the osC community seems to work really well. We will continue providing consultative support and are evaluating other ways to provide promotional and financial support.
  23. pbreit

    PayPal_Shopping_Cart_IPN

    IPN is more reliable for at least 3 reasons: 1) there is no dependence on the shopper pressing Continue OR the Auto-Return working. 2) IPN retries until it is successful. 3) IPN handles the echeck situation. A second IPN posts when the echeck clears. The importance of using IPN exclusively cannot be overstated. It's OK not to provide protection from the script being accessed from other than PayPal but precautions must be in place: 1) ipn.business must equal button.business 2) ipn.mc_gross must equal button.amount and ipn.mc_currency must equal button.currency_code 3) ipn.txn_id must not have been previously processed (for payment_status=Completed) 4) the IPN must be authenticated with a "VERIFIED" response
  24. pbreit

    PayPal_Shopping_Cart_IPN

    We strongly advise relying exclusively on the IPN for payment information if possible. This is by far the most reliable means for receiving the payment details.
  25. pbreit

    Core PayPal Support

    About a month ago we got rid of the sign up requirement if the merchant is US. We hope to extend this to non-US merchants shortly. IPN is the most reliable way for PayPal to transmit payment details to osC. I think we've achieved a 99% rate of delivering IPNs in 3 seconds or less so that shouldn't be an issue. Auto-Return is not necessary and seems to have led to a number of issues with one of the contributions. I think a lot of osC/PayPal issues would go away if IPN were implented in the core distribution.
×