Disable all payment methods if an account is in a non-approved state

[csmcneill]

Describe the bug

When onboarding a WooPayments account that was pending approval, APMs (like all three BNPL options) could still be enabled.

If a merchant onboards and their account is still pending verification, their experience can be pretty fragmented depending on how quickly they begin navigating the WooPayments settings.

For example, viewing Payments > Settings immediately after onboarding shows that card payments are disabled, but all other payment methods are available.

However, checking back a bit later shows that cards and BNPL offerings are all disabled — but not other APMs.

While I could enable these APMs as an admin, they were not offered on checkout because of the account's status.

To Reproduce

1. Onboard WooPayments in such a way that an account still needs to be approved.
2. Navigate to Payments > Settings prior to approval.
3. Note that some APMs (specifically BNPLs in my test) can be enabled.
4. Enable these APMs.
5. Try to make a purchase using the enabled APMs.
6. You will be unable to due to the account's pending status.

Actual behavior

If a WooPayments account is still pending approval, a merchant can enable some APMs while the account is unable to accept payments.

Screenshots

Expected behavior

All payment methods are immediately disabled if an account is in a non-approved state.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context

Related to pbUcTB-447-p2#inconsistent-settings-when-account-pending-verification

[pierorocca]

@csmcneill are we sure this is not permissible? I thought these payment types require additional approvals above and beyond the card and payout approvals? It would make sense that these could be initiated in parallel.

@vladolaru do you have more insight into how Stripe handles this?

[csmcneill]

@pierorocca This is feedback from the first BNPL Audit Call, which coincided with Stripe's issues with verifying US accounts (see pbUcTB-45E-p2 for more details).

Because the account was in a Pending verification state, it could not accept any payments (card, BNPL, etc.) until it was approved.

[pierorocca]

Thanks @csmcneill I wonder if our assumptions during the review were wrong. I know acceptance is not possible in that pending state. I see that as being different / independent to applying to accept additional methods. Ideally a merchant could toggle payment methods on and off regardless of the top level state of the account.

A similar example shown here from Wix's site shows that despite Payments not yet being enabled because I'm not on the paid plan, I can still toggle other payment methods. I can't use them yet. This I think is super important for sites that may be in test mode, or where we want to defer onboarding to late stages but still allow the merchant to preview functionality.

@vladolaru in case you have any insight on how Stripe handles top level merchant onboarding vs. individual payment methods.

[vladolaru]

in case you have any insight on how Stripe handles top level merchant onboarding vs. individual payment methods.

@pierorocca, the main current philosophy around payment methods and their relationship with the merchant account onboarding state revolves around these:

• an account can't do anything until they accept the Stripe TOS at the end of the Stripe-hosted onboarding; this doesn't mean that all verifications have passed, just that this is a prerequisite
• each payment method is tied to an account capability that comes with certain requirements and verifications
• the behavior for live payments and test payments (or the new Stripe sandboxes) is intentionally similar, including KYC and verifications (even for test mode accounts, the verifications are deliberately not instantaneous to simulate the live process)
• we don't have a way today to circumvent KYC and use a mock account (we will once we have our APIv2 platform up and running)

From my POV, the issue at hand is pretty straightforward: ensure alignment between checkout behavior and settings behavior, as there is a wrongful disconnect today (settings don't reflect checkout behavior).

[gpressutto5]

Please add your planning poker estimate with Zenhub @FangedParakeet

[gpressutto5]

The checkbox components check the capability status for each payment method to either display a checkbox or an exclamation mark. When a new Stripe account is created but not yet activated, the capabilities for Credit Card, and Giropay for some reason, are pending_verification, but the others are unrequested as they were never requested.

Initial state


If we enable other methods and save the settings, the page will not reload and the newly enabled payment methods will seem enabled. However, if we refresh the page, we will see they are actually pending_verification. Can you confirm this is the case for you, @csmcneill? On the site you captured the image above, if you refresh the page before completing the account setup, do the methods display as pending?

Bancontact and EPS are pending after refreshing the page


Now, these methods are pending, which means they will be enabled as soon as the missing step is completed in the account setup. After finishing the setup and coming back we can see only Giropay is still pending, but it is not pending_verification anymore, it is pending, which means the capability is pending approval, and in my experience it was approved automatically after a few seconds.

After account setup


The main problem I see here is that the settings page is not refreshed after saving, and the checkbox assumes it was successfully enabled. We need to find a way to update the account_data in the front after saving the settings, either by refreshing the page or making a new request to get the data.

Another thing that makes this process confusing is that the checkboxes have a spinner but don't actually make a request. They are only saved after we scroll down and click the save button. I'm not sure if this is always the case, but I couldn't replicate a different scenario. Because of this, when it switches to an enabled state after the spinner, it looks like a confirmation that it went right and the method is enabled, but it is not true.

Checkbox spinner


Now, considering we fixed this, and the correct state is displayed in the front after saving the settings, do you think it is ok to leave the checkboxes available for activation before the account is setup, or should we disable all payment methods' checkboxes before the initial setup is fully done? (i.e., payments_enabled is false, or the Credit Card method is Pending approval)

[csmcneill]

Can you confirm this is the case for you, @csmcneill? On the site you captured the image above, if you refresh the page before completing the account setup, do the methods display as pending?

This is hard for me to test because the site where I experienced this was due to delayed verification issues for all US accounts: pbUcTB-45E-p2

This issue meant that it could take hours for an account to go through the verification process. Unless we can intentionally delay the verification process (e.g., using specific merchant information during the KYC in sandbox mode), I'm not sure how we can test this.

[gpressutto5]

I simulated this scenario by finishing KYC without confirming the documents. When the KYC is over and you need to wait a few seconds before Stripe asks for your document, you ignore it and go back to the store. The only difference is that this simulates a "Pending activation" status instead of a "Pending approval".

[pierorocca]

If we enable other methods and save the settings, the page will not reload and the newly enabled payment methods will seem enabled

The main problem I see here is that the settings page is not refreshed after saving, and the checkbox assumes it was successfully enabled.

I've experienced the same and an entire page of "pending approvals" statuses because the main account hasn't yet been approved seems excessive.

I looked at a few competitors to see how their flows are setup.

1. Shopify only has Credit/Debit and express checkouts + Shop Pay available. Everything else requires addons via different flows so their primary flow is much simpler than ours.

2. Looking at WIX, who like WooPayments offer a broader selection of payment methods their sequence is:

WIX Flow: Connect gateway -> Select Payment Methods -> AML/KYC/Onboarding -> Onboarded -> Add more payment methods or gateways

WooPayments flow: Connect gateway -> AML/KYC/Onboarding -> Pending Approval for Credit/Debit + Giropay? -> Add more payment methods or gateways (account may be in pending or approved state at this time)

The challenge with the WooPayments flow is the account is in this indeterminate state for a period of time. WIX is more of a synchronous flow whereas ours is async which creates the confusion. The lack of automated refreshes further confuses.

The benefit of the WIX type flow is that it allows default toggled on + recommendations, and the approval flow can enable everything the merchant wants in one shot. There only one approval event for the user to experience. The async flow imo can create a choppier flow.

Pre-choosing payment methods before onboarding also allows testing cart and checkout, or at least to see what it looks like on the store, without having to go through onboarding until it's truly needed.

What's your recommendation @gpressutto5 in the short term?

[gpressutto5]

I agree an entire page of "pending approvals" statuses seems excessive. The best short-term solution consists of two parts:

1. Resolve the checkbox ambiguity by removing the spinner (we need to check if it is really not being used for anything else before doing so)
2. Get an updated account data object after saving the settings and make sure the UI updates accordingly.

I'm unassigning myself from this issue because I'm on Support Rotation this week. If you agree with the suggestion above, we have the actionables for this issue, and anyone can work on it.

[pierorocca]

This works as a stopgap until the entire settings page gets a redesign. Thanks for sharing your recommendations.

I'm hoping in that redesign that we prevent users from being able to click enable options while in this middle state. Ideally, they choose their options prior to onboarding and underwriting in order to streamline the flow.