We've been getting a bunch of 905 errors back from Adyen, resulting in failmail.
In some (not all) cases, this appears to be due to a missing payment submethod. 107254500 logs show the first & second donation attempts have no submethod, but then on the third attempt, we get a submethod (visa) and the donation complete as expected.
Currently, we're reliant on Adyen telling us the payment submethod as part of the onSubmit event pasted below for convenience (check comment):
// The code should be available in state.data.paymentMethod.brand, but // sometimes it's not there. We can usually still find it via component. payment_submethod: mapAdyenSubmethod( state.data.paymentMethod.brand || component.state.brand )
The code comments suggest it's possible for us to not always receive the payment submethod in the state property, but what if the fallback is also unreliable? The frontend code that expects this data is here
Let's add some extra logging to this mapping method to work out what's going on here. Luckily we already have a MediaWiki API that we can use to log client-side errors, we're using it here for the generic window.error events:
( function ( $, mw ) {
window.onerror = function ( message, file, line, col, error ) {
var postdata = {
action: 'logPaymentsFormError',
message: message,
file: file,
line: line,
col: col,
userAgent: navigator.userAgent
};
if ( error && error.stack ) {
postdata.stack = error.stack;
}
$.ajax( {
url: mw.util.wikiScript( 'api' ),
data: postdata,
dataType: 'json',
type: 'POST'
} );
};
} )( jQuery, mediaWiki );We can reuse the bits above that make the ajax call to the ClientErrorApi API. The submethod/brandCode mapper method can then call this new code if Adyen does not supply us with a submethod, hopefully allowing us to dig in and work out why this might be happening.