Jump to content

Supertex

Members
  • Content count

    309
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Supertex

  1. Supertex

    Looking For Testers: New PayPal App

    I'll jump on this either tomorrow or Monday and report back. Thank you -so- much for your dedication to this.
  2. Supertex

    [Contribution] - USPS Methods

    Hrm...a fresh look on the next day means I should have posted last night. So for anyone else that's looking for this: Adding this below line 692 did exactly what I wanted: $title = str_replace(array('<sup>', '</sup>', '®', '™', '®', '™', ' 1-Day', ' 2-Day', ' 3-Day', ' Military', ' DPO'), '', $title); How does an idiot like myself stumble across solutions? Makes me think I'm setting myself up for a catastrophe.
  3. Supertex

    [Contribution] - USPS Methods

    @@AedeaInnovations First off, thank you for your contributions to this. Only after being involved with an osC store for the last few years do I really understand what's poured into these things by the community. I switched to this module because the insurance works. I ship a great deal to foreign countries, and USPS is the only reasonably priced AND insured international option. The insurance is a must. However, on the domestic side, I've been trying to get rid of the '1-Day' etc, displayed after Priority Mail. I see in the code (I think) where there's a str_replace line that should be cleaning this off, but its not. Im talking right around line 1250. But that line seems to pass the cleaned results to $qid instead of $qname. Mind you, I know just enough to be dangerous, as far as coding goes...but I switched $qid to $qname, and it did actually clean the name, but it lost a method on the customer side, and logged the "unsupported shipping types" to the DB, making the admin side unable to be edited. Then I noticed the module sent emails to me, about unsupported types and your github. I stopped there last night, and decided to look at it again today, after uninstalling and reinstalling the module via admin. I think perhaps I should be working elsewhere in the code...perhaps around line 875, just before methods are returned? Or should the code near 1250 be cleaning it, except I'm missing the htmlspecialchars_decode function? I don't find that in includes/functions/html_output.php, or in general.php. This kind of thing is nightmarish for me. I could really use some guidance.
  4. Supertex

    Looking For Testers: New PayPal App

    iPad Air, and after disabling return and removing return url, results are the same: "Could not verify the PayPal transacton. Please try again." Checked twice. I can test with Android if need be.
  5. Supertex

    Looking For Testers: New PayPal App

    Turning off PDT fixed the desktop transactions, but mobile devices still show the same error. Red PS with -notify-validate Request: cmd _notify-validate Response:
  6. Supertex

    Looking For Testers: New PayPal App

    It was/is set to ON, as pursuant to fixing the previous module's mobile visitors. I'll shut it off and rerun.
  7. Supertex

    Looking For Testers: New PayPal App

    First I see in red: PS _notify-validate ---------------------------------- The Request: cmd -notify-validate GET tx (omitted) GET st Completed GET amt 6.62 GET cc USD GET cm 5 GET item_number The Response: --------------------------------- Then I see in green: PS _notify-validate[iPN] --------------------------------- The Request: mc_gross 6.62 invoice 278 protection_eligibility Eligible address_status confirmed item_number1 tax 0.50 item_number2 payer_id (omitted) address_street 123 Street payment_date 13:52:17 Nov 11, 2014 PST payment_status Completed charset UTF-8 address_zip 90210 mc_shipping 0.00 mc_handling 0.00 first_name Test mc_fee 0.49 address_country_code US address_name Bob Villa notify_version 3.8 custom 5 payer_status verified business store@@MySitesOnline.com address_country United States num_cart_items 2 mc_handling1 0.00 mc_handling2 0.00 address_city My City verify_sign (omitted) payer_email sandbox-buyer@@myispnet.com mc_shipping1 0.00 mc_shipping2 0.00 txn_id (omitted) payment_type instant last_name Buyer address_state CA item_name1 Test Item 1 receiver_email sandbox-facilitator@@MySitesOnline.com item_name2 Domestic Low Order Fee: payment_fee 0.49 quantity1 1 quantity2 1 receiver_id (omitted) txn_type cart mc_gross_1 1.12 mc_currency USD mc_gross_2 5.00 residence_country US test_ipn 1 transaction_subject 5 payment_gross 6.62 ipn_track_id (omitted) cmd _notify-validate The reply is "Verified"
  8. Supertex

    Looking For Testers: New PayPal App

    That didnt work well...a moment.
  9. @@Bob Terveuren http://forums.oscommerce.com/topic/398299-looking-for-testers-new-paypal-app/ May be of interest.
  10. Supertex

    Looking For Testers: New PayPal App

    Installed, and after some painful wait times with the sandbox, everything is in place and seems good. I ran a few test transactions, and they all processed stock and emails, but upon returning to the store: " Could not verify the PayPal transaction. Please try again." Is this a bug, or have I made a mistake in the installation?
  11. Supertex

    New UPS XML Shipping Module available

    ?> <p align="right" style="clear: both; padding: 15px 50px 0 0;"><?php //echo TEXT_ALTERNATIVE_CHECKOUT_METHODS; ?></p> <?php reset($initialize_checkout_methods); while (list(, $value) = each($initialize_checkout_methods)) { ?> <p align="right"><?php // echo $value; ?></p> <?php catalog/shopping_cart.php Mine is modded, so I'd say look around line 200 or so. I just commented out the echo.
  12. OSC 2.3.1, PayPal Standard - newest release: 3.2 TLDR: Look at the last text section. I've read quite a few posts about how this works, but I'm still very unclear about how this "should" flow. If there's a definitive post that would clear me up, could someone point me to it? Here's how it currently does flow for me: Customer populates a cart, moves through shipping and arrives at checkout_payment. They have 2 options - Money Order and PayPal. A) Money Order - No order exists until they click "confirm order" on checkout_confirmation. Then the order is set to "Awaiting Money Order", stock is deducted, and emails sent. B) PayPal - Order exists immediately when they click "continue" to move to checkout_confirmation. - Order in admin list is set to "Preparing [PayPal Standard]" - Order status within the order itself shows "No Order Status History Available" - No stock deducted. 1) They click on "Confirm Order" & are taken to PayPal site. - No order status change. - No stock deducted. **Here is where the order should come into existence** 2) They actually submit a payment on the PayPal site. - Order status in admin order list changes to "Pending" - Order status within the order itself shows "PayPal [Transactions]" with comment PayPal IPN Verified. - No stock is deducted - Cart is not cleared - No emails dispatched, either to me or the customer, from my store 3) After the transaction, 2 things can happen: Customer is either auto-returned, or shown a "return to store" button. 4a) They're auto-returned - Order status in admin order list remains "Pending." - Order status within the order itself now shows 3 status lines: 1 - PayPal [Transactions], with comment PayPal IPN Verified. 2 - PayPal [Transactions], with comment PayPal Verified. 3 - Pending, with no comment. - Customer & store notification emails are sent. - Stock is deducted. - Cart is cleared. 4b) They click "Return to Store." - Same as above. 4c) They do not return to the store, whether they closed the browser, hit the 'back' button, fumbled the keyboard and got hung up...whatever. - Order status in admin order list remains "Pending." - Order status within the order itself shows "PayPal [Transactions]" with comment PayPal IPN Verified. - No stock is deducted - No emails are sent. Question about "B": I have several orders that never progress beyond this point. Is there not a way to prevent these "stale" orders from acquiring an order id, and therefore appearing in the admin orders list before they actually click to move to PayPal? Or better yet, until payment has been submitted? It just makes unnecessary clutter in the list, and there's no need to actually SEE them, that I can think of, except it's been an indicator that the customer has cookies disabled, and had issues with the process. Even being able to filter these out of the order list without altering the order query would be nice, but I can't readily alter the drop-down filter to exclude only this type of order, since it just adds a status type to the url. It's either all types or a single type. As I understand, this is somehow necessary to the functionality of the IPN. Question about "3": Why is this different for some customers? I've run transactions on Windows, Mac, Chrome, FF, IE, and Safari, and have had mixed outcomes. I realize this doesn't directly have anything to do with OSC, but surely someone has some insight on, or experience with, this oddity. Is it a browser/OS combination, or is it the way my store is set up? Question about "4a": Should I be seeing both IPN Verified, AND Verified, or do I have some redundancy at work? Question about "4c": Perhaps this is related to the previous question. I thought the IPN had functionality built in, to "finish" the order even if the customer did not return to the site, And by "finish" I mean send notification emails to the customer and to me, and more importantly, deduct stock. If that is in fact how it should be working, can someone suggest where I've gone wrong?
  13. @@radhavallabh May help: catalog/includes/languages/(your language)/modules/payment/paypal_standard.php: define('MODULE_PAYMENT_PAYPAL_STANDARD_TEXT_PAYPAL_RETURN_BUTTON', 'Complete My Order'); // Maximum length 60 characters, otherwise it is ignored. This replaces "Return to (store name)" button text on the PayPal site with "Complete My Order" indicating more clearly the need to return to the store. Original text implies nothing.
  14. @@Harald Ponce de Leon A thought for the next release... Add into admin module options: Force address override: Y/N $parameters['address_override'] = '0'; Reasonable request? I've had problems for certain customers if left to "1".
  15. Supertex

    osc 2.3.1 Unique Order Number

    Yeah...I thought about this all night. Too easy to orphan an order - or worse. I was thinking of adding orders_invoice_id to the appropriate tables and instead of changing the order number/id, just adding a function that will use this addon's mechanic to create the invoice number at the same time the order_id is created. Then just change the files that display order number, and the only place order_id matters is in the mechanics. Only thing I'd like to change is that instead of using the timestamp in the invoice number, I'd rather it just use ymd + 001 and increment by one per order per day. 9 is a more reasonable length than 12. Not sure what the logic to do that would involve. Would still be a pain to keep track of modifying new files, but at least no issues from orders that are not recorded...
  16. Best I can find at the moment, is to edit checkout_confirmation.php or the associated language file to include something like: "You must return to this store after PayPal is completed to finalize your order." I plan on adding it to the code that display the PayPal logo at the bottom of the page.
  17. @@radhavallabh I believe you're probably having the same issues as I am. A customer MUST return to the store to have stock updated and send order process emails. The problem is not affected by this fix - this only fixes mobile device purchases, which were completely broken (again, Ty Bob). Currently, if a non-mobile customer pays with PP account, they are auto-returned. If they do NOT log into PP, and instead pay with a credit card, they are NOT auto-returned - they must 'click to return to (store)' For click-to-return, there is no message telling them it's required, so some simply don't return. For those orders...no emails...no stock updates.
  18. Supertex

    osc 2.3.1 Unique Order Number

    Nvm....forgot that the PayPal module does everything that checkout_process.php does, one step earlier.
  19. Supertex

    osc 2.3.1 Unique Order Number

    Hrm...seems like a pretty old thread, but ...you have to take the "-" out of the date("dmy-His") entry. Otherwise it truncates the number, excluding time, and all orders place on the same day would have the same number. My problem is that it breaks PayPal. Works great for invoice numbers but I get [TEP STOP] when I try to check out with PP. I double-checked paypal_standard.php and all instances of (int)$order_id have been changed to $order_id. Not real sure where to look for the problem. And what's the chances I need to do the same to the IPN listener?...or any other PP associated files? Suggestions?
  20. This was a great find indeed. Kudos, Bob. Now if we could just get IPN to handle stock decrements and order emails....we'd be golden. HPDL said he was looking at that for the next PayPal Standard release - at least the stock portion of it.
  21. Supertex

    Paypal Order Emails Not Being Sent

    Not sure if you guys are still working on this, but I have the same trouble with it. Something I thought I'd toss in the mix: if IPN handles stock deductions, what happens when you make a full or partial refund, and paypal tosses another IPN your way? Does it deduct twice? I only ask because I just recently figured out that refunds actually do create status updates on the site's invoice for the affected order. And since IPN doesn't currently handle stock decriment...we're more often faced with a need to refund, due to stock numbers' inaccuracies.
  22. Supertex

    USPS Rate V4, Intl Rate V2 (official support thread)

    Thanks for the reply - and the work you've done here. I don't know how different this one is from the 'methods v7.3.1' but the extra services in that module work. I dont know if the international rate prices are right, but I know it just errors on domestic addresses. Since that one doesn't give "N/S/H," I wondered if there might be a problem with the checkbox fields in V4_V2. Might be a temporary fix, to use 7.3.1 for international with insurance, and use V4 intl rate v2 for domestic, as we dont offer insurance on domestic. But if both modules are named USPS, is there a "right" way to change the name of one of them? I tried unsuccessfully to clone V4_V2 (usps.php and usps_48.php) once before. Selections came up right, but it looped back to checkout_shipping.php when I tried to move on to checkout_payment.php. So I don't know what I missed. I'll keep digging. I look forward to the new module you're developing.
  23. Supertex

    USPS Rate V4, Intl Rate V2 (official support thread)

    @@kymation can you confirm the functionality of the extra services in this module?
  24. Supertex

    USPS Rate V4, Intl Rate V2 (official support thread)

    Are the extra services working in this module? I have "insurance" set to "S," for international, but it's not showing up on the shipping selection, and the cost definitely does not reflect insurance. Handling is 2.00, Shipping cost (US to Thailand) is 49.74, insurance on the valuation was 15.10. Price shown to customer is 51.74.
  25. @@Harald Ponce de Leon Thank you for the response, and for your many hours of dedication. Then it is normal to see on the order invoice, both PayPal IPN Verified, AND Paypal Verified, and I am not misconfigured? I thought perhaps only one or the other should show.
×