Ecommerce: Can complete purchase successfully with user who should be banned by export compliance

[briangrossman]

Steps to Reproduce

• Create a new account with one of the names listed as a banned name (p. 23 of Simple Order API Doc
• Order a course using the same name

Expected Behavior

• User is not allowed to place an order

Actual Behavior

• User is able to successfully place the order

[pdpinch]

I believe there is a parameter we can set in the simple order API request that requests a banned name check before allowing the transaction to complete.

see https://developer.cybersource.com/library/documentation/dev_guides/Verification_Svcs_SO_API/html/Topics/Requesting_Export_Compliance.htm

[jkachel]

While there is a parameter that can be set in the Simple Order API for this, we use Secure Acceptance, which does not have this feature. However, since the benefit of Secure Acceptance is that we don't handle the payment process flow at all, this ideally should be handled on the CyberSource side of things if it can.

There's a couple pathways we can go down for this:

• We can run this up through CyberSource support to see why people on the BIS denied persons list are allowed to complete transactions. I'd think they'd be filtered at this point but they may assume transactions are generally for non-restricted items (and thus place the onus of verification on us). But, there may be an option that's not exposed to us to turn on denied persons list filtering. I haven't seen anything like that in the documentation but I'd assume that's come up before.
• We can additionally add a step to the signup process to validate new learners against the entity list, and deny ones that are on the list. We may need to add some additional data capture to the signup process for this to work. The BIS provides the list in computer-parsable format so it'd be relatively easy to deal with but we'd have to spend a bit of time figuring out a good way to implement this. (It'd probably look like the exchange rate list code but still would require a bit of thought.)
• We can use the Secure Order API enough to use just the Verification Services part of it to run the transaction through Export Compliance before completing the order through the normal Secure Acceptance payment flow. We would again need to add some more fields to the user profile - we'd need to track the learner's address to be able to use this API.

The easiest thing would be to see if there's a way to make the Secure Acceptance flow run the check against the denied persons list automatically, since that's the point where the address is collected currently.

[pdpinch]

@jkachel I'm about to open some issues for updating the user profile data we collect. What fields would we need to add to make this work (with options 2 and 3 on your list above)?

Or can we try again to find out why the first option isn't working?

[jkachel]

Matching against the various lists can be done simply with the name and country info we already collect; however, it'd be best to at least get a city and state for a more accurate match. (The denied persons list is here, it doesn't take too long to find a name that'd be pretty common.) We could capture this information at checkout.

Focusing on option 2, in addition to caching a list locally (to the application) there's a free-to-use API that can be hit to run checks against all the various lists. (I mentioned the denied persons list and that's the most important, I think, for our purposes, but there's others and they roll them all up into a consolidated list.) The documentation for this, including info about the downloadable lists, is here: https://www.trade.gov/consolidated-screening-list . (I think this is the easiest and quickest option to implement since the other two involve wrangling CyberSource support in some sort of manner.)