Advanced Card Processing payments get stuck on the first attempt when using CheckoutWC (2689) #2393
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 therender()
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