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

[FEATURE] describe actual state of async payment flow #1478

Open
mkucmus opened this issue Nov 25, 2024 · 3 comments
Open

[FEATURE] describe actual state of async payment flow #1478

mkucmus opened this issue Nov 25, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request payment

Comments

@mkucmus
Copy link
Collaborator

mkucmus commented Nov 25, 2024

Description

  • describe the current state
  • report the bugs
  • find solutions

Use Case

  • there are still hidden parts in async payment process like what would happen in case of fail or unfinished happy path

Proposed Solution

No response

Alternatives Considered

No response

Additional Context

No response

@mkucmus mkucmus added the enhancement New feature or request label Nov 25, 2024
@mkucmus mkucmus self-assigned this Nov 25, 2024
@mkucmus mkucmus moved this to In Progress in Composable Frontends Nov 25, 2024
@mkucmus
Copy link
Collaborator Author

mkucmus commented Nov 28, 2024

issues found:

  • no feedback about failed transaction after redirection from finalize-payment route - there is no info what went wrong, customer is just redirected back to frontend app URL according to handlePayment URL defined, with no details
  • the async flow is not fully headless, the finalizeTransaction action takes place in storefront context
  • sometimes the payment handler does not handle additional parameters required to finish transaction, like success token for payment intent for credit cards

@BrocksiNet
Copy link
Collaborator

Push it :)

@mkucmus
Copy link
Collaborator Author

mkucmus commented Jan 15, 2025

Failed payment scenario for async flow

Missing details what went wrong

Solutions

  • PaymentException instance with additionalInformation enforced - check whether the Payment Handler Interface can have it defined (🛠️backend )
  • errorUrl redirection in case of external payment -> always contain provider internal error code (currently we have error code but need to ensure if it’s internal or external) (🛠️backend)

Those two goals can be supported by extending the docs here: https://developer.shopware.com/docs/v6.7/guides/plugins/plugins/checkout/payment/add-payment-plugin.html
(🛠️docs)

Async payment flow in general

Missing route to finalize-payment in store-api scope

not really headless, API should also keep one route for default storefront exposed


Solution

add new endpoint (🛠️backend)

can also works like double opt-in solution for registration - user is being redirected to the client app with set of hashes and tokens to be used by api-client to inform the backend


Not intuitive flow to re-pay for an order

Solution

  • Re-enable payment without changing the payment method (🛠️backend)

like having new endpoint to initiate the payment again -> under the hood it closes the last transaction and does what handle payment do: /order/{id}/handle-payment or the existing one

  • System job to clean open transactions which haven’t been updated for X minutes (depending on payment provider limits (🛠️backend/infra)

@mkucmus mkucmus moved this from In Progress to Developer Backlog in Composable Frontends Jan 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request payment
Projects
Status: Developer Backlog
Development

No branches or pull requests

2 participants