Some contexts do not accommodate disruptions in their workflow, such as creating core entities, Webforms, etc. To allow people to make payments in these contexts, a payment reference form element was developed that handled the entire payment workflow in a separate window/tab. However, for sites that only offer payment methods that process payments inline (e.g. do not redirect the user off-site) this is overkill and not user friendly.
The first step to solving this would be to make payment method controllers specify whether they disrupt the workflow they're being used in or not. Next to that payments need a setting that tells Payment whether they are made in a context that supports inline payment methods, so they can be matched to each other.
Comments
Comment #1
xanoComment #2
xanoPayment method plugins now have an "interrupts_execution" annotation property for their operations that indicates whether execution of the operation will result in the current code execution being interrupted.
Comment #3
xano#1980392: Payment operations introduced the property for payment method plugins. #2034365: Convert contexts to plugins introduces a similar property for contexts.
Comment #4
xanoLet's not add a flag to context plugins, as they describe the context of the payment and not the context in which an operation is being executed. These things probably need to go through \Drupal\payment\Plugin\payment\method\PaymentMethodInterface::paymentOperationAccess().
Comment #5
xanoWe'll continue this in #1860956: Support inline payment methods in payment method selectors.