The answer appears to be that something is getting put in the session by the omnipay code that the CiviCRM caching code doesn't like. Here's the issue that describes the full details:
And here's a patch Eileen includes that seems to have solved the issue:
I think session issues sounds more like a D8/CiviCRM configuration issue rather than a D8WFC module issue.
I just confirmed that D8WFC can do live payments (authenticated and anonymous) with iATS Payments. I'm sorry we don't use any Omnipay processors with any of our clients so I can't try to confirm your scenario. Perhaps check on Mattermost -> chat....
welcome to CiviCRM - we had some communications with a potential client who had an in-house developer that did some work on SwipeHQ. Suggest you try getting in touch with him via this question or give me a buzz and I will put you in touch if that is helpful. Adding a SwipeHQ tag
I narrowed the issue down to what goes on in initialize() in civicrm-core/CRM/Core/Session.php.
When calling the contribution page directly resetScope() is called, which calls initialize() without any argument. When going through webform only createScope() gets called with $isRead set to TRUE every time. This means initialize() is only ever run with $isRead ...
Only PayPal can tell you the reasons for an account limitation and the steps required to resolve it.
PCI stands for "Payment Card Industry", and is a standards body that Visa and MasterCard and other payment card providers are part of. They created a set of standards that merchants must meet to be compliant. PayPal does not validate, and is not responsible ...
I got this to work with the following meta-data file. omnipay_Migs_TwoParty.mgd.php. Since the field in the code is merchantAccessCode I changed the label for passwords to "Merchant access code'. Both the debugger and the error message show this.
'name' => 'OmniPay - MIGS',
'entity' => 'payment_processor_type',
'params' => ...