Jump to content

cdetdi

Members
  • Content count

    48
  • Joined

  • Last visited

  • Days Won

    1

Reputation Activity

  1. Like
    cdetdi reacted to burt in When is /ext/.../standard_ipn used?   
    As far as I recall, it depends on one thing; whichever "signal" gets back to the shop first.
    If the customer arrives back before the IPN...
    -or-
    If the IPN arrives before the customer.
     
  2. Like
    cdetdi reacted to ecartz in When is /ext/.../standard_ipn used?   
    Just to highlight something that others have noted in passing but may not have stated explicitly enough.  If you want to test the IPN path, then don't go back to your site after making the payment.  Because if you just click quickly through everything, chances are that you get back to the site before PayPal sends the IPN.  So act like a customer.  When you get to the screen that says something like "Click here to return to the merchant", close the browser window.  Then your test will work like their order.  Because some customers do exactly that. 
    Note that both the IPN and the click through flow use the paypal_standard file.  The IPN file also has some logic of its own.  This contrasts to the logic triggered from the checkout_process file. 
  3. Like
    cdetdi reacted to BrockleyJohn in When is /ext/.../standard_ipn used?   
    In case you don't know, IPN (instant payment notification) is a feature so paypal automatically contacts your site to tell it about things that happen with payments in paypal - like it's been paid, if it was an echeque that it's cleared, it's been refunded and so on. It's a security feature making it harder for hackers to steal from you by faking paymennts. If you also run an ebay account and you look at your paypal logs in osc you'll see that it tells your site about those payments too!
    All of these IPNs trigger the ipn listener in /ext/... if the listener can find a related order it will write a history record that you can see in admin.
    Now, sometimes when people pay with paypal they don't come back to your site - maybe they don't wait long enough after hitting pay and rush back to looking at porn or their connection drops or whatever. So if the ipn listener gets notified that the payment is there and the order is in the Preparing status, it will go ahead and complete the order, do the stock adjustments, send the emails and so on. If the order is already in the later status (eg Pending), it will just log the history record.
    For the people that do come back to your site and get there before the IPN, when they go through checkout_process that executes the code in the paypal_standard module and changes the order status, stock levels and sends out emails.
    So... both files handle setting an order to paid, the stock and so on - but for any given order it was one or the other. If you want to know which it was, you can tell from the history records (if IPN handled it the change of status history is nearly simultaneous with the IPN email).
    The IPN listener file always handles processing the IPN notification but it may only write a history if the other got there first
    The standard module always handles the user going through checkout_process to checkout_success but it may not do anything for the order if the other got there first
    Both routes need to work properly and if you're changing one for some reason you also need to change the other.
  4. Like
    cdetdi reacted to 14steve14 in From Frozen to Phoenix   
    Its not free because of only the coders. Its free because a very limited number of store owners and developers, have invested in the project financially so the coders can keep coding. If everyone subscribed to the theory that nothing is for free and contributed, then the project would be far further forward than it is now. Of the hundreds of users on this forum only a small proportion feel the need to keep the project moving forward whilst others sit back, criticise and moan. If they are not happy why are they using this software? We have no idea, but probably because they get something for nothing that earns them money. We all cannot expect coders to invest their time into a project which is freely given away without being able to at least get a meagre sum for their time work and experience. They could be doing fully paid work if they choose. Nobody works for nothing.
    No its not. Everyone can download the code for free from this site or from Github. What people cant get is what they don't deserve. Non contributors get the basic code base, whilst those that contribute get something back for their contribution. Its those that contribute and get the updated code early that are doing all the testing that is required before a release is made to the core files that are available to download from this site, which everyone can download. It really is that simple. Contribute and get rewarded for doing so. Its not difficult. Some should be thankful that they get what they already get. it could and should change in the future. Change the record and stop whining.
  5. Like
    cdetdi reacted to burt in From Frozen to Phoenix   
    If every shopowner put in 25% the effort/time/money that you do Corey, Phoenix could employ people to perform upgrades and testing.   We'd be golden.
    But instead we have 60 businesses who have put into the pot over the last 10 months - subsidising hundreds of other businesses, so there is no money to do much of anything.
    And people like the previous poster, who just post utter nonsense.
  6. Like
    cdetdi got a reaction from 14steve14 in From Frozen to Phoenix   
    I think you're under estimating the pain of a broken shop here...
    Upgrades that you publish are excellent, but they don't come with (not saying they should come with) a list of stuff that will break if you install the update.  As another owner said, if a shipping module is just outright broken, a 10 minute upgrade might turn into 1-2 HOURS of missed sales.  And those are hours you don't get back - you still need to do shipping, inventory, payroll, customer service etc.  
    In MY experience, being completely honest, upgrades are never 5-10 minutes, but typically 1-2 hours or longer.  My shop is very customized, so don't take this as a complaint.  This is sharing the fact that a small .x upgrade is a BIG deal for owners like myself.  
    I'm hopping from frozen to Phoenix and it isn't painless.  Stuff you expect to work just doesn't, and I'm updating/patching most of the things I use on the daily.
    I appreciate the move to "Approved Add-Ons", but I think it needs to go farther.  If an add-on is "Approved" it must also mean that is is updated regularly - if it falls 30 days or more behind the current release it must loose its approved status.  This means that users like myself can have confidence that we can upgrade to the latest release, with all approved modules in a timely fashion.
  7. Like
    cdetdi got a reaction from 14steve14 in From Frozen to Phoenix   
    I think you're under estimating the pain of a broken shop here...
    Upgrades that you publish are excellent, but they don't come with (not saying they should come with) a list of stuff that will break if you install the update.  As another owner said, if a shipping module is just outright broken, a 10 minute upgrade might turn into 1-2 HOURS of missed sales.  And those are hours you don't get back - you still need to do shipping, inventory, payroll, customer service etc.  
    In MY experience, being completely honest, upgrades are never 5-10 minutes, but typically 1-2 hours or longer.  My shop is very customized, so don't take this as a complaint.  This is sharing the fact that a small .x upgrade is a BIG deal for owners like myself.  
    I'm hopping from frozen to Phoenix and it isn't painless.  Stuff you expect to work just doesn't, and I'm updating/patching most of the things I use on the daily.
    I appreciate the move to "Approved Add-Ons", but I think it needs to go farther.  If an add-on is "Approved" it must also mean that is is updated regularly - if it falls 30 days or more behind the current release it must loose its approved status.  This means that users like myself can have confidence that we can upgrade to the latest release, with all approved modules in a timely fashion.
  8. Like
    cdetdi got a reaction from 14steve14 in From Frozen to Phoenix   
    I think you're under estimating the pain of a broken shop here...
    Upgrades that you publish are excellent, but they don't come with (not saying they should come with) a list of stuff that will break if you install the update.  As another owner said, if a shipping module is just outright broken, a 10 minute upgrade might turn into 1-2 HOURS of missed sales.  And those are hours you don't get back - you still need to do shipping, inventory, payroll, customer service etc.  
    In MY experience, being completely honest, upgrades are never 5-10 minutes, but typically 1-2 hours or longer.  My shop is very customized, so don't take this as a complaint.  This is sharing the fact that a small .x upgrade is a BIG deal for owners like myself.  
    I'm hopping from frozen to Phoenix and it isn't painless.  Stuff you expect to work just doesn't, and I'm updating/patching most of the things I use on the daily.
    I appreciate the move to "Approved Add-Ons", but I think it needs to go farther.  If an add-on is "Approved" it must also mean that is is updated regularly - if it falls 30 days or more behind the current release it must loose its approved status.  This means that users like myself can have confidence that we can upgrade to the latest release, with all approved modules in a timely fashion.
  9. Like
    cdetdi reacted to rsthornton in USPS with Dimensions Support v 6.54.1 Install Issue   
    I reinstalled the module and finally resolved the issue, I had to add the Country of Origin option in admin -> Configuration -> Shipping/Packaging
    Thank you very much for your help
  10. Like
    cdetdi got a reaction from alix32 in Horizontal Megamenu   
    Jim - are there plans to bring this up to Phoenix?  Willing to sponsor the development, let me know.
  11. Like
    cdetdi got a reaction from Mac2256 in Google reCAPTCHA v3   
    Small nit:
    For v3 Recaptcha Google recommends enabling the tracking code on EVERY page load, not just ones you want to protect.  This enables Google to create a traffic profile.  e.g. if a customer has been shopping the site normally but then submits a contact us in a suspicious way (e.g. did a copy-paste autofill which was very fast) Google takes into account the non-spammy behavior beforehand.
    It looks like your module only loads on the hooked pages, I suggest loading the tracking code on all pages following Google's guidance.
  12. Like
    cdetdi reacted to BrockleyJohn in Paypal Standard Payments Failing   
    @ecartz it already is - that is the one from core; I have checked since. The failing sites are using an older cert that doesn't have the root and intermediate certs in.
  13. Like
    cdetdi reacted to ecartz in Paypal Standard Payments Failing   
    Yes, that's what I see too.  That file is also available at https://github.com/gburton/CE-Phoenix/blob/master/ext/modules/payment/paypal/paypal.com.crt
    So, new troubleshooting step for PayPal problems.  Verify that one has the latest version of that file. 
  14. Like
    cdetdi reacted to mfleeson in Paypal Standard Payments Failing   
    Thanks so much for this thread guys. I started having issues with paypal payments not coming through and I've been chasing all around the place trying to find the issue.
    The old version was missing both DigiCert High Assurance EV Root CA and DigiCert Global Root G2 (SHA-256)
    I ran araxis merge on the phoenix 1.0.5.1 cert and the one downloaded from here and they're identical.
    Thank you.
    Can I suggest this gets made as an announcement in the forums so people know to update.
    On a slightly different issue my Paypal app says its version 5.0.10 and then pops up An update is available for this App! . Clicking the button does nothing and from what I can see on the forum it's the latest version. Anyone got ideas?
    Cheers
    Mark
  15. Like
    cdetdi reacted to BrockleyJohn in Paypal Standard Payments Failing   
    Thanks Martin, that fixed it for my customer's site.
    @saxcbr @Cary @cdetdi @Mac Fly please try copying the above file into your shops.
    You can then try resending an IPN from your Paypal account (finding it is tortuous):
    log in to PP, hit cog > Account settings
    scroll down to website payments on left menu
    choose Update next to Instant Payment Notifications
    in the middle of the first line of text, hit the link IPN History page
    This shows you a list of IPNs, defaulting to the last 24 hours - change the period if necessary and select one to resend
    [fingers crossed]
     
  16. Like
    cdetdi reacted to mhsuffolk in Paypal Standard Payments Failing   
    paypal.com.crt
  17. Like
    cdetdi got a reaction from burt in Paypal Standard Payments Failing   
    Submitted.
  18. Like
    cdetdi reacted to Cary in Paypal Standard Payments Failing   
    From Earlier:
    Your case was created. We do strive to provide a response as soon as possible and remember you can also always log back into the this same portal and view/update your ticket. If you do not hear anything from us, chances are your spam settings or ISP may potentially be blocking our email. We suggest you check your spam settings.
    Our response will come from the email address merchanttechsupport@paypal.com
    Our email address can be added to list of approved contacts to reduce it from being blocked
     
    https://www.paypal-support.com
  19. Like
    cdetdi got a reaction from John W in Paypal Express Dropping Tax Calculation   
    Fixed for now - I added a function in general that looks to see if the PAYMENTREQUEST_0_TAXAMT is in the Paypal array which then turns on the tax rate I need.   The fact that this works suggests that it was the shop that calculated the rate by itself (disregarding the PayPal return) and the shop was dropping the tax rate.
×