Feedback Round 2

[chickenn00dle]

Hey y'all. Great work on this so far! 🙇‍♂️

I've got another round of feedback which I'll use this issue to track and share. If you'd prefer I open individual issues for each point instead, let me know and I'll close this and do that.

Anyway, here goes:

Settings Page

• Incorrect tooltip for all Credit Messaging ratio settings: https://d.pr/i/MPH5d0
• The 1x4 ratio option is a bit awkward.

This is what it looks like on Storefront on desktop: https://d.pr/i/wmCDVw

And on mobile: https://d.pr/i/sqzBA3

(Product and Cart messaging banners are similar)

In both cases, there is a large chunk of unused space. Is this intentional? If so, would you consider changing this ratio to reduce this empty space?

• The installation prefix setting name might be a bit confusing. Is this prefix specific to invoices? If so, we may want to rename this to Invoice prefix to make this clearer for merchants.

• Settings page is a bit cluttered. Right now, if I want to disable buttons on the mini-cart, for example, it is a bit of a pain sifting through all of the different buttons and messaging sections to find what I am looking for. It might be better to have all button settings together, all messaging settings together, or even separate these into different tabs to reduce the number of settings on a single page.

Checkout

• No logging for failed Credit Card payments. I have only confirmed this with the Credit Card/Debit button, but for example, when something goes wrong I see the following message: https://d.pr/i/P0VWpB

Despite logging being enabled, no log file/entry is generated for this.

• Related to the above, is it possible to default to guest checkout and not force users to create a PayPal account when re-attempting to pay with Credit Card?

For example, this is what I see when attempting to retry: https://d.pr/i/4jztQh

But in WooCommerce PayPal Checkout Payment Gateway, I see the following which doesn't require creating an account: https://d.pr/i/WrmfDW

• Also related to the above, on failure, it would be nice to not have to try again, and be able to select a different payment method. Right now, after selecting the Credit Card/Debit button, the other methods disappear and don't return on failure.

Code

• I'm seeing some coding standards violations in several PHP files. Mostly just spacing/indentation at beginning of lines and missing doc comments.

[chickenn00dle]

Here is some more feedback, this time specific to Card Processing:

Card Processing

• Disabling a card type doesn't actually prevent the payment from completing successfully. I'm not sure if this is because I am in Sandbox.
• Font size for Card Processing form is inconsistent with the rest of the checkout page: https://d.pr/i/FDJlBr
• When multiple logos are displayed, they appear a bit cramped.

Here is a screenshot comparing logos with another payment gateway. Perhaps we could add a tiny bit of margin as is done in Stripe: https://d.pr/i/da3wul

• When Elo, Hiper, and/or JCB logos are shown, they are not sized properly in the order received screen: https://d.pr/i/7quZtH
• On the same screen, the payment details section showing img HTML: https://d.pr/i/bU5O2P

The following are not really necessary, but just some thoughts I had when testing:

• 3D secure is not really an option so perhaps it doesn't need its own field. Maybe we could move this to the description text under PayPal Card Processing: https://d.pr/i/sZzmLZ
• Should merchants be able to display logos for Credit Cards that are disabled? I'm thinking a merchant may inadvertently select the same credit card for both of these fields, which may lead to some confusion for their customers.

[chickenn00dle]

This will be the last bit of feedback for this issue as it's getting quite full:

OAuth

• Requiring an email before being able to connect adds some confusion to the process.

Is it possible to display the button by default, and delay inputting an email address to this step: https://d.pr/i/GZJA4D

Another option might be to allow merchants to kick off the connection process as soon as they enter an email (without requiring the additional step of saving settings).

As it stands, when I first see the PPCP settings page, it's unclear I need to input my PayPal email address to kick off the connection process. And once I do figure this out, the next state displays the following: https://d.pr/i/wky3bH

The Email Address field indicates I am connected, but the button indicates otherwise. I imagine some merchants may stop here without finalizing the connection process until they later realize payments aren't working as they expect.

• When in the progressive state, after a merchant inputs an email address, but before finishing the connection process, sandbox cannot be toggled.

This may be a consequence of only allowing either Sandbox or Live, but I imagine some merchants may either inadvertently select, or forget to check the Sandbox option when entering an email address. In these cases, it would be nice to not lock in which mode the site ends up in so a reset isn't required to get it right.

Honestly, it would be best if merchants could store both sandbox and production credentials, but I think this is something @jorgeatorres already brought up.

• Allow merchants to hide manual creds after toggling them into view: https://d.pr/i/LlsFXR

[websupporter]

Font size for Card Processing form is inconsistent with the rest of the checkout page

Some thoughts on styling: The single DCC fields are actually iFrames, which makes it really hard to properly style them. There are some styling options, I can utilize. What currently is done. The rendered HTML the browser receives gets the default input fields from the \WC_Gateway_CC. With window.getComputedStyle() I read the styling values and apply those to the wrapper, which will replace the default input fields and where the iFrame is placed in.

I can add some optional styling to the input fields inside the iframe (somehow I didn't commit this yet, will do), but overall these iFrames will produce inconsistencies. So, as an example: When I apply the font-size, it will still appear bigger as the necessary font is not loaded in the iFrame and the sans-serif-fallback will be used.

Here an overlay of the closest I came so far in trying to stay as close as possible to the theme styles:

[websupporter]

Thanks, @chickenn00dle for the feedback. I have created separate issues for the concerns, so discussions and PRs can be more focused. Will close this issue in favour of the new ones.