CSC level and card tokens

Steve Rittler

We're using Checkout to properly and securely vault cards.

We then invoke the /payments/v1/checkout/transaction to process a payment completely without issue. So far so good.

We then attempt to (effectively immediately) run another transaction (using /payments/v1/transactions this time) against the very same card token but can't seem to get it to process unless the CSC level in that payment configuration is set to none. The transactions are rejected with error_code 4 - A validation error occurred. Validation error code: <CardSecurityCodeIsRequired> Validation error message <A card security code is required.>

Is the “Full” CSC level really demanding a code for a vaulted, previously-used card token or is there some other transaction parameter we should be passing along to bypass it?

Steve Rittler

For anyone else who runs into this, or future me who forgets the outcome:

I spoke with Blackbaud today. Long and short of it is, regardless of the prior use of a card token, the CSC and AVS settings on the payment configuration reign supreme. So even a reused, previously good-to-go credit card token is useless if the payment config you're running the transaction through has the CSC level set to anything other than None.

Blackbaud advised creating a separate, dedicated payment configuration with both AVS and CSC levels at None to be used specifically for this second-transaction-against-a-tokenized-card process.

Obviously you'd only do this if you had reasonable safeguards up around the payment form (which we do - it's both deep inside the registration process and in at least one case also behind a login) so it couldn't be used for card scraping.

We had also pursued the is_backoffice flag and an SCA exemption, but those would be truly special case exceptions to bypass CSC requirements, which creating a new payment configuration does neatly and in a reasonably sheltered manner.