Hi, I see you triaged this task as Unbreak Now. Do you need help?

Nope but thanks for checking! This and one other task are highest priority for the current fr-tech sprint. I wanted to be absolutely sure this was clear relative to other tasks in the sprint.

I would suggest high priority for that, per https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels . I am regularly reviewing all UBN tasks.

Change 674822 had a related patch set uploaded (by AndyRussG; author: AndyRussG):
[mediawiki/extensions/DonationInterface@master] [DO NOT MERGE] Omnipay Adyen test

https://gerrit.wikimedia.org/r/674822

The attached patch adds a modified Adyen adapter that uses Omipay classes to generate data for redirect to Adyen.

To use it, run composer install, then in the root MediaWiki directory, run composer require guzzlehttp/guzzle:7.3.0.

Open an Adyen form at Special:AdyenGateway2. For example, if you have payments on localhost:9001, try this URL. From there, click on a payment method. The Adyen form will have been generated using Omnipay code.

The relevant code is in adyen_gateway_2/adyen.adapter2.php, starting on line 243:

// **************************************
// We've built the response using our normal stuff; now let's try
// to do the same using Omnipay

$omniGateway = Omnipay\Omnipay::create( 'Adyen\Hpp' );

global $wgAdyenGatewayAccountInfo;

$omniGateway->initialize([
		'secret' => $wgAdyenGatewayAccountInfo['WikimediaDonations']['Skins'][array_keys($wgAdyenGatewayAccountInfo['WikimediaDonations']['Skins'])[1]]['SharedSecret'],
		'skinCode' => array_keys($wgAdyenGatewayAccountInfo['WikimediaDonations']['Skins'])[1],
		'merchantAccount' => 'WikimediaDonations',
		'testMode' => true,
		'currency' => 'USD',
		'countryCode' => 'US',
]);

$omniCard = new Omnipay\Common\CreditCard([
		'firstName' => 'Joe',
		'lastName' => 'Bloggs',
		'billingAddress1' => '1 Montgomery Street',
		'billingState' => 'CA',
		'billingCity' => 'San Francisco',
		'billingPostcode' => '94104',
		'billingCountry' => 'US',
		'email' =>  'jason@example.co.uk',
]);

$omniRequest = $omniGateway->authorize([
		'transactionId' => '12345',
		'amount' => 9.99,
		// The returnUrl can be defined in the account, and overridden here.
		'returnUrl' => 'https://example.co.uk/your/return/endpoint',
		'card' => $omniCard,
]);

$omniResponse = $omniRequest->send();

// Replace our normal response data for redirect with omni stuff
$this->transaction_response->setData( $omniResponse->getData() );

//**********************************

describe the pros and cons of using this system at WMF

Cons:

• The abstractions provided by Omnipay are more limited than the ones we have and need. This is because Omnipay tries to generalize over dozens of processors, and does not provide abstractions for aspects of integrations that we want to generalize (such as recurring).
• Many Omnipay-based integrations that we might be interested in have few contributors and/or are semi-abandoned, and don't have the features we need.
• Possible additional tangle of dependencies/versions of required libraries.

Pros:

• Over the long term, if we write code that integrates with an existing payment processor library, it's more likely that others would use our code as part of their own systems, and maybe even contribute to it. This would be a good way to help build and support free software communities.

Would this system help us integrate faster or lower maintenance effort?

There is a small possibility that if we use an up-to-date Omnipay-based integration that has an sizeable, active community, we might obtain some benefit. (This is not the case for any Omnipay-based Adyen integration.) Over the long term, if we find a way to include Omnipay core abstractions in new integrations we develop, we might also generate some synergy with free software communities, and our code might be re-used somewhere. However, this option should be considered together with a careful analysis of our own requirements and architectural goals.

would you want to move to this system and deprecate any of our current systems?

Definitely not.

Here are a few more notes:

Examples of normalization stuff we have that Omnipay doesn't:

• Data transformers
• Noramlized data validation

Stuff about Omnipay to note:

• Thinner and less featureful abstraction layer.
• Separation of concerns set up differently (for example http stuff integrated, though I suppose we may not need to use just that part).
• Also has stuff we'd never use, such as shopping cart item.
• Nice layout of classes, though.
• Common (not processor-specific) code is moderately clean.

Maybe if we were to rebuild our entire stack from scratch, using Omnipay abstractions as a basis and implementing the stuff we need as we go along, it might have ended up cleaner.

Recommendation: First take time to review architectural directions and medium-term requirements for the entire Fundraising stack, and make a plan for incremental improvements. Then, depending on the results of that process, possibly implement a new processor based on Omnipay or Payum abstractions.