Updated: Comment #N
Problem/Motivation
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.
Proposed resolution
- Let payment method plugins specify if they interrupt the regular workflow when they execute a payment.
- Use inline entity forms to display payment forms, or leverage #2182263: Attach field form elements to payment forms, if the selected payment method does not disrupt the workflow. Use the existing new-window-approach if it does.
Remaining tasks
...
User interface changes
Minor with backwards compatibility.
API changes
None.
Original report
The payment reference widget uses a separate ab/window for processing payments, which should be a more user friendly workflow if payment methods can be used within a context's workflow.
To do: add a a new form element (which in version 2 should replace the existing one) that can be used anywhere and only opens a new window if a user wants to pay using a payment method that is off-site.
See #1860954: Better support for inline/non-off-site payment methods.
| Comment | File | Size | Author |
|---|---|---|---|
| #77 | payment_1860956_77.patch | 205.57 KB | xano |
| #77 | interdiff.txt | 1.53 KB | xano |
Comments
Comment #1
xanoComment #2
xanoDepends on #2105793: Port Payment Reference Field.
Comment #3
xanoThis may also depend on the D8 version of Inline Entity Form.
Comment #4
xano#2006248: Add an EmbeddableFormInterface so that FormInterface can delegate to multiple objects might remove the need for Inline Entity Form.
Comment #5
xanoComment #6
xanoMarked #1860954: Better support for inline/non-off-site payment methods as a duplicate of this issue.
Comment #7
xanoWe can actually do this already. Look at
EntityFormControlleras an example. It just called the proceduralfield_attach_*()functions and contains some extra logic that we should be able to duplicate.//Edit: take a look at what #2095195: Remove deprecated field_attach_form_*() does.
Comment #8
xanoPreliminary patch.
Comment #9
xanoComment #10
xanoRe-roll.
Comment #13
xanoComment #15
xanoComment #18
xanoComment #20
xano18: payment_1860956_17.patch queued for re-testing.
Comment #22
xano18: payment_1860956_17.patch queued for re-testing.
Comment #24
xanoComment #26
xanoComment #27
xanoComment #28
xanoRe-roll.
Comment #30
xano28: payment_1860956_28.patch queued for re-testing.
Comment #32
xanoRe-roll.
Comment #34
xanoRe-roll.
Comment #36
xanoWe may want to use a method rather than a plugin definition property to define whether or not a plugin interrupts the request. Some plugins may or may not interrupts the request based on the current context, and we don't want them to declare themselves and interruptive all the time, because plugin definitions are not dynamic.
Comment #37
xanoRe-roll, but with many failures.
Comment #38
xanoComment #40
xanoComment #42
xanoComment #44
xanoComment #46
xanoComment #47
xanoComment #48
xanoAJAX works now. The workflow needs some polishing, and entity form submission does not work yet.
Comment #50
xanoEverything works, and I added increased test coverage. What's left is to get full test coverage and to add support for fields.
Comment #52
xanoComment #54
xanoComment #56
xanoComment #60
xanoKeeping up with recent changes in HEAD.
Comment #61
xanoImproved test coverage.
Comment #66
xanoComment #68
xanoComment #70
xanoRe-roll because of #2329401: Rename \Drupal\payment\Queue to DatabaseQueue.
Comment #72
xanoComment #75
xanoRe-roll.
Comment #77
xanoKeeping up with recent changes in Payment.
Comment #78
xano