Forum Replies Created

Viewing 15 replies - 31 through 45 (of 61 total)
  • Thread Starter esd3104

    (@esd3104)

    Might be related but I have turned on debugging. When doing so I see a few “fatal error” logs an example below (slight obfuscation of full paths). Doesn’t seem to be at the same time as the failed AVS order.

    2023-11-28T04:23:11+00:00 CRITICAL Uncaught Error: Call to a member function get_payment_method() on bool in /home/namgbr/public_html/wp-content/plugins/godaddy-payments/src/Gateways/PayInPersonGateway.php:150
    Stack trace:
    #0 /public_html/wp-includes/class-wp-hook.php(324): GoDaddy\WooCommerce\Poynt\Gateways\PayInPersonGateway->maybe_render_held_order_received_text('Thank you. Your...', false)
    #1 /public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters('Thank you. Your...', Array)
    #2 /public_html/wp-content/plugins/woocommerce/templates/checkout/order-received.php(34): apply_filters('woocommerce_tha...', 'Thank you. Your...', false)
    #3 /public_html/wp-content/plugins/woocommerce/includes/wc-core-functions.php(345): include('/home/namgbr/pu...')
    #4 /public_html/wp-content/plugins/woocommerce/includes/shortcodes/class-wc-shortcode-checkout.php(312): wc_get_template('checkout/order-...', Array)
    #5 /public_html/wp-content/plugins/woocommerce/includes/shortcodes/class-w in /home/namgbr/public_html/wp-content/plugins/godaddy-payments/src/Gateways/PayInPersonGateway.php on line 150
    Thread Starter esd3104

    (@esd3104)

    Yes I have an open ticket. It appears that a fix to the iframe or backend systems has been implemented 03-Oct-2023 – initial testing shows that it seems to be working.

    Thread Starter esd3104

    (@esd3104)

    Yes I received contact from Benjamin. Looks like everyone is working on this together then.

    Thread Starter esd3104

    (@esd3104)

    So you can connect internally please refer to ticket: CAS-114923

    Thread Starter esd3104

    (@esd3104)

    WordPress: 6.3.1

    Woocommerce 7.9.0

    WP Database: MySQL 8.0.34

    I also called in and discussed with GDP Payments Advanced Support and provided more information directly via email along with screenshots I can’t/won’t post here publicly to show the error. From my dashboard look at the last 3 transactions before it broke: #CA430C15, #0BA4C077 and #D551DC27. Everything after that I had to disable my address validation.

    Nothing changed on my website plugin or software-wise at the time this stopped working.

    Thread Starter esd3104

    (@esd3104)

    OK – that seems to work. Thanks.

    You folks obviously know your way around WC as I have used your most helpful Sequential Order Numbers for WooCommerce plugin for quite some time. I’m just confused why this payment plugin seems to break/not play nicely with the usual tools WC provides to customize things and needs a code snippet and another plugin to make this work. I have some other customizations with code snippets so the risk of any updates to GDP breaking something seems high.

    Thread Starter esd3104

    (@esd3104)

    Thanks – I have implemented that but it makes no difference. When GDP is the payment option you are somehow overriding even this third way of setting the “place order” button text. I tried making GDP the only gateway and still no difference. I have left it setup with 2 gateways. When another gateway is selected, it says “Make Payment”. When you select GDP as the payment method it says “Place Order”.

    Like I said this is the same even with GDP as the only gateway. If you change back and forth between the payment method you see the text change back and forth. Something about your code overrides any attempt to change the default “Place Order” text for the WC button.

    Thread Starter esd3104

    (@esd3104)

    Excellent, thank you. That seems to work and nicely makes things neat and tidy!

    Thread Starter esd3104

    (@esd3104)

    Thanks for the follow up. Ideally for me there’d be no scroll bar – it just looks silly and there’s no reason for a scroll bar.

    I did some more playing and this seems to be somehow Chromium related. On Desktop at 1920*1080 and using Firefox, no scroll bar. On Edge Version 110.0.1587.69 (Official build) (64-bit) and Chrome Version 111.0.5563.65 (Official Build) (64-bit) I see the scroll bar.

    Ideally there would be no scroll bar – there’s no reason for it to be there because there’s more than enough room on the screen to see all fields.

    Ideally, per some other comments about font size for input fields etc., the iframe would be more aware of the screen resolution / device and adapt accordingly. In the desktop case there’s no need for a scroll bar, the input fields could be larger and use a larger font, and in the desktop case the Expiry and CVC could be on one line.

    It appears, just a guess, the iframe is designed for mobile device screens, on which it works well, albeit the small fonts, but it doesn’t respond well to being on a laptop or desktop size screen/resolution. My 02 cents.

    Thread Starter esd3104

    (@esd3104)

    No thanks. We won’t save enough by using GDP to cover the costs.

    Thread Starter esd3104

    (@esd3104)

    The auto refresh thing (onchange) I did some research and played around with some stuff I found online and tried to adapt but I couldn’t get anything to work. Beyond my abilities as I don’t really do PHP and or CSS for a living. ??

    Thread Starter esd3104

    (@esd3104)

    OK – thanks. I guess every theme and site is different but your iframe doesn’t seem to play nicely the way the built in payment gateways do. I get the iframe is there for PCI Compliance etc. but it still needs to look OK. The stupid unneeded scroll bar is visually bad enough that I won’t use this for live payments until it looks OK on my site.

    Thread Starter esd3104

    (@esd3104)

    If you drill down all the way into a payout report, you can find the WooCommerce order number. Not exactly convenient though ??

    I’ve used Stripe for years so I am not used to having to dig this hard to find details when trying to reconcile what transactions and looking at a payout/payment to see which orders were included with that. If you’re doing QuickBooks or other accounting on the back end (as I am) then sometimes you need to check/reconcile the bank deposit with the card payments – possible to make an error entering a sales order in QB. So it needs to be easy to see what orders are part of which payment. Your payment report does that but it’s several clicks deep vs being easy to see in the main dashboard as other providers do.

    Thread Starter esd3104

    (@esd3104)

    I just checked another, low volume, site I setup with GDP and I see exactly the same thing. No mention of WooCommerce and just “Smart Terminal”. Just figured I’d mention this as its not isolated to one site.

    Thread Starter esd3104

    (@esd3104)

    Thanks – I had been playing with CSS via my browser inspect tools but CSS not really my thing – I know just enough to be dangerous. ??
    I have applied the custom CSS but it doesn’t seem to solve the problem. The problem only appears on a desktop PC with a 27inch screen running 1920*1080. On laptops and phones it seems to be OK.

    Poking around a little more it seems like the custom CSS is being overridden by CSS coming from PaymentForm.css:7 or PaymetnForm.css:12 served by your cdn. If I play in the inspector changing the height to 230px (not 97% as seems to be coming in and overriding the custom CSS) then the scroll bar goes away.

    I did try adding !important after the height value in the custom CSS but that didn’t see to do it.

    If you have any other suggestions that would be great, understand this is not part of defined support.

    Ideally the iframe would behave more like the regular WC payment entry forms and use the space available and adapt based on screen size/resolution/device type.

Viewing 15 replies - 31 through 45 (of 61 total)