Worldpay: update authorize request for AFT

[rachelkirk]

CER-2099

Update authorize request to include AFT fields when 3DS is invoked. Previous test cases cover this change, so no further tests are necessary.

[jcreiff]

Hey @rachelkirk I was thinking about this change some more, related to 3DS scenario that led us here, and I'm wondering if we need to add some additional logic to the aft_request method to fully enable this to be compatible with the 3DS flow.

I notice that the build_aft_request method looks like a truncated version of build_authorization_request - outside of the aft_data bits, the authorize logic has all the same sub-methods, and then some. In particular, it seems relevant that add_additional_3ds_data and add_3ds_exemption are present in the authorize step but missing from the build_aft_request logic.

Is it naive to assume that simply adding those two sub-methods into the AFT logic would cover our bases for this AFT/SCA scenario? Could we write a remote test to validate that these request components will play nicely together?

[jcreiff]

One other thing that came to me as I was tinkering with the existing implementation in Postman: I think the WP docs undersold how many fields they will enforce the "can't be blank or empty" validation that previously forced us to adjust the handling of middle and address2. I came to this realization because a sample request I sent was barking at me for excluding state

I tried to vet this theory by commenting out various lines of the aft_options in the existing remote test and in I think we also need to apply similar handling to omit the following fields if not supplied:

• address1
• postalCode
• city
• state
  (all the above are in both the sender and recipient blocks)

also:

• telephoneNumber
• the entire birthDate object (if someone submits telephoneNumber but no birthDate, we'll hit a NoMethodError in the add_date_element logic