Fix Bug where some BTThreeDSecureRequest Default Values Returned Errors Unexpectedly

[jaxdesmarais]

Summary of changes

• Fix bug where defaults for BTThreeDSecureRequest.accountType, BTThreeDSecureRequest.requestedExemptionType, and BTThreeDSecureRequest.dfReferenceID were improperly returning an error if not passed into the request
• The Any in these cases for the dictionary should be optional to allow for nil values (behavior in v5) - currently we were defaulting to an empty string in the nil case which is invalid
• Add UnitTest for this case in the future

Checklist

• Added a changelog entry

Authors

• @jaxdesmarais

[sarahkoop]

Curious why we want to pass nil rather than just not including the param in the request if it's null? Is the behavior the same either way?

[jaxdesmarais]

Yeah the behavior would be the same - we could do either technically, seems like v5 did a nil check then passed the key/value if not nil (code here). I'm fine with either option and this is slightly cleaner than a bunch of if/else below but if folks felt strongly we could extract these out.

It's also worth noting when we do compactMapValues below we strip out any nil key/values so either option has the same effect. From a playground:

let myDictionary: [String: Any?] = [
    "string1": "hasValue",
    "string2": nil,
    "int1": 0
]

print(myDictionary)
print(myDictionary.compactMapValues { $0 })

The above would return with compactMapValues stripping out nil values:

["string2": nil, "string1": Optional("hasValue"), "int1": Optional(0)] // print(myDictionary)
["int1": 0, "string1": "hasValue"] // print(myDictionary.compactMapValues { $0 })

[sarahkoop]

Ah cool thanks for the explanation!

[jaxdesmarais]

No problem! compactMapValues is pretty cool and was definitely a benefit of the Swift move. 🥳