Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Advanced Card Processing payments get stuck on the first attempt when using CheckoutWC (2689) #2393

Open
wants to merge 3 commits into
base: trunk
Choose a base branch
from

Conversation

stracker-phil
Copy link
Collaborator

@stracker-phil stracker-phil commented Jul 5, 2024

Problem

When using CheckoutWC, payments via Advanced Card Processing did not work.

Two different problems were observed:


Issue 1

Symptom: The "Debit & Credit Cards" fields were not displayed during checkout

Background

The CheckoutWC plugin creates a custom checkout page, ignoring block editor contents. If the checkout page previously used block checkout, our plugin responded with incorrect JS configuration, leading to issues with payment elements initialization.

Solution

Implemented a compatibility filter to check for the CheckoutWC template. Adjusted JS settings accordingly to ensure proper initialization of the classic checkout logic.

Commit: a349c87


Issue 2

Symptom: The card payment resulted in a "pending" mode with an endless loading animation

Background

Sometimes, the CheckoutWC would invoke the CardFieldRenderer::render() JS method multiple times. This seems to be related to caching or JS loading order, and usually only happens once per session.

The render method is responsible for injecting the credit card form into the checkout form and linking the fields to the submit button.

Our code was laid out to render exactly once. On the second render call, the original DOM fields were not updated again, but new submit listeners were created. Short: The DOM and the JS events got out of sync.

Solution

A small refactoring of the CardFieldRenderer class now allows calling the render() method multiple times without any side effects.

The logic to prepare field-options (styling, placeholders) is extracted to a JS getter, which parses the DOM once on first access. All subsequent render calls will use those initial field options to re-render the input fields.

Commit: c685a08

@stracker-phil stracker-phil changed the title 🔧 Added compatibility fix for CheckoutWC Advanced Card Processing payments get stuck on the first attempt when using CheckoutWC (2689) Jul 5, 2024
Apply new eslint styling
Addresses an issue where multiple `render()` calls would disconnect the input fields in the DOM with the JS logic inside the `CardFieldsRenderer`

Problematic logic in old code:
```
if ( nameField ) {
    …
    nameField.remove();
}
```

The condition was only executed on first `render()` call.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants