Skip to content

Add an experimental Payment Elements embedded checkout display mode - #3

Draft
acirtautas wants to merge 1 commit into
mainfrom
payment-elements
Draft

Add an experimental Payment Elements embedded checkout display mode#3
acirtautas wants to merge 1 commit into
mainfrom
payment-elements

Conversation

@acirtautas

Copy link
Copy Markdown
Contributor

Summary

Adds a third gateway display_mode that renders EveryPay's embedded checkout (card, bank and wallet form) on a page of the shop instead of redirecting to the hosted payment page.

  • The capture handler sends mobile_payment: true and stores the returned mobile_access_token together with the SDK options in the payment request response data.
  • EveryPayHttpResponseProvider renders the new templates/shop/payment_elements.html.twig through the new PaymentElementsViewFactory.
  • The hosted-page redirect remains the fallback whenever the token or any confirm() field is missing from the API response.

Experimental status

The Payment Elements JS SDK is undocumented for custom integrations. The contract used here was reverse-engineered from EveryPay's own WooCommerce 2.x plugin and the SDK bundle, and is recorded in docs/everypay-api.md. The mode ships marked experimental and exempt from the stability contract until EveryPay confirms the SDK for custom integrations — this PR stays a draft until that confirmation arrives.

Testing

  • vendor/bin/phpunit — 103 tests green (unit + functional, including new coverage for the capture handler, response provider, view factory and admin form)
  • vendor/bin/behat --strict — 15 scenarios green (new embedded-checkout scenario included)
  • vendor/bin/phpstan analyse (level 9) and vendor/bin/ecs check — clean
  • Translations updated for all four locales (en, lt, et, lv); et/lv are machine-assisted

A third gateway display_mode renders EveryPay's embedded checkout (card,
bank and wallet form) on a page of the shop instead of redirecting. The
capture handler sends mobile_payment: true and stores the returned
mobile_access_token with the SDK options in the payment request response
data; the response provider renders the new template through
PaymentElementsViewFactory and falls back to the hosted page redirect
whenever the token or any confirm() field is missing.

The SDK is undocumented for custom integrations - the contract was
extracted from EveryPay's own WooCommerce 2.x plugin and the SDK bundle,
and is recorded in docs/everypay-api.md. The mode ships marked
experimental and exempt from the stability contract until EveryPay
confirms the SDK.
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.

1 participant