Invalid OTS Token

[blackwood821]

Hi,

I'm currently integrating Accept.js into my site to become PCI compliant. Here was my old server-side work flow:

Create new monthly subscription:

1. Authorize credit card for first month payment (send credit card info: number, exp date, etc.)
2. If authorization succeeds
   1. Create subscription (send credit card info: number, exp date, etc.) and start billing from the second month since the first month payment is handled now
   2. Capture previous authorization
3. If authorization fails
   1. Void authorization transaction (send credit card info: number, exp date, etc.)

Now I want to tweak this work flow so that I send the opaqueData (dataDescriptor and dataValue) in place of the card info. So the new work flow is now:

Create new monthly subscription:

1. Authorize credit card for first month payment (send opaqueData)
2. If authorization succeeds
   1. Create subscription (send opaqueData) and start billing from the second month since the first month payment is handled now
   2. Capture previous authorization
3. If authorization fails
   1. Void authorization transaction(send opaqueData)

Step 1 succeeds but step 2.1 fails with the response "Invalid OTS Token". I understand that this is because the dataValue token has already been processed in step 1 (the authorization). So my question is, how do I handle not sending the same dataValue in step 2.1 without sending card info since my server no longer receives that? Also, are neither the card info nor the opaqueData required for steps 2.2 and 3.1?

An option I'm considering:

1. Create a customer profile by setting the (createProfile parameter to true) in the authorization request (if it doesn't already default to true). Then pass the customer profile info instead of the opaqueData in the Create Subscription request.

Please let me know if this is the recommended solution or if there is a better solution. Thanks.

[Anurag · Accepted solution]

Yes the option you mentioned is a good way of creating profile from Accept TOken , and then using the profile to create a subscription . 

[worldmodern]

I am trying to implement accept.js with similar requirements.

We process simple payments, sometimes create a subscription after the payment if they ordered a recurring membership, and usually give the customer the option to save their card info. (even for normal payment transactions without subscription).

So we implement all this with up to three API transactions one after the next:

- charge the card

- save customer/payment profile

- create subscription

This was all working fine when submitting the card info to our server and sending it along for each transaction.

But now it seems that the OTS token can only be used for one transaction.  So I took the advice here and tried to use the CreateProfile = true option on the initial charge a card transaction.  I get an error telling that create profile is not supported for "this payment method"  (I supposed when using accept.js token).

The payment goes through but profile response error comes back like so:

<profileResponse>
<messages>
<resultCode>
Error
</resultCode>
<message>
<code>
E00103
</code>
<text>
Customer profile creation failed. This payment method does not support profile creation.
</text>
</message>
</messages>
</profileResponse>

I also get invalid OTS token if I try to create the subscription after the payment transaction.

I am coming to the conclusion that it's not really possible to use accept.js with these requirements.

What do you think?

Thanks

KR

[Anurag]

Hi @worldmodern

You can use the one time Accept  token to first create the payment  profile via API 

https://developer.authorize.net/api/reference/index.html#customer-profiles-create-customer-profile

or 

https://developer.authorize.net/api/reference/index.html#customer-profiles-create-customer-payment-p...

opaqueData	Required. Contains dataDescriptor and dataValue.
dataDescriptor	Required. Specifies how the request should be processed. The value of dataDescriptor is based on the source of the value of dataValue.	String, 128 characters. Use COMMON.ACCEPT.INAPP.PAYMENTfor Accept transactions.
dataValue	Required. Base64 encoded data that contains encrypted payment data. The payment gateway expects the encrypted payment data and meta data for the encryption keys.	String, 8192 characters.

and pass the paymentProfile in the createTransaction or to create subscription from it . 

https://developer.authorize.net/api/reference/index.html#payment-transactions-charge-a-customer-prof...

or 

https://developer.authorize.net/api/reference/index.html#recurring-billing-create-a-subscription-fro...

[worldmodern]

Thanks for quick response.  Funny after thinking it over overnight, I realized that's what I should try next - create the profile first and then run the payment and then create subscription if necessary.  So never uyse the token more than once.  If it's a refular payment with no subscription and customer did not request to save info, then I will run the payment normally directly from the token.

But one thing I'm wondering - what about AVS check?  I suppose create profile does not check AVS right?  So what if a bad address is entered (pretty frequent case).  Will the payment request kick it out as an error?  Then I suppose I would want to delete the payment profile since it's not really valid.  Up till now, I only was creating the profile AFTER the payment was successful.

Finally what about CVV ?  Does create token validate the CVV?  I noticed on my sandbox transactions that the payment txn shows CVV not processed even though I submitted CVV to get the token.

I will restructure my code this morning and give this all a try.

Thanks

KR

[worldmodern]

Hi - 

So I got this basically working.

When taking a transaction with accept token, it now does the following:

- if customer requested to save card info OR if order includes a subscription, create customer profile and payment profile

- then charge the card using the payment profile

- if charge fails, remove the payment profile and return

- if success, continue to create subscription from payment profile

One problem I am having is that when I created the token, I just tried using an invalid CVV.  I used 4 digits not 3 for a Visa card.  

The tokenizer did not raise any error and the transaction went through with CVV Not Processed = Not Processed.

This ties back to my earlier question:  how do we enforce CVV to be correct using Accept.js?

Thanks

KR

[Campos369]

Mobdro

---

@blackwood821 wrote:

Hi,

I'm currently integrating Accept.js into my site to become PCI compliant. Here was my old server-side work flow:

Create new monthly subscription:

1. Authorize credit card for first month payment (send credit card info: number, exp date, etc.)
2. If authorization succeeds
   1. Create subscription (send credit card info: number, exp date, etc.) and start billing from the second month since the first month payment is handled now
   2. Capture previous authorization
3. If authorization fails
   1. Void authorization transaction (send credit card info: number, exp date, etc.)

Now I want to tweak this work flow so that I send the opaqueData (dataDescriptor and dataValue) in place of the card info. So the new work flow is now:

Create new monthly subscription:

1. Authorize credit card for first month payment (send opaqueData)
2. If authorization succeeds
   1. Create subscription (send opaqueData) and start billing from the second month since the first month payment is handled now
   2. Capture previous authorization
3. If authorization fails
   1. Void authorization transaction(send opaqueData)

Step 1 succeeds but step 2.1 fails with the response "Invalid OTS Token". I understand that this is because the dataValue token has already been processed in step 1 (the authorization). So my question is, how do I handle not sending the same dataValue in step 2.1 without sending card info since my server no longer receives that? Also, are neither the card info nor the opaqueData required for steps 2.2 and 3.1?

An option I'm considering:

1. Create a customer profile by setting the (createProfile parameter to true) in the authorization request (if it doesn't already default to true). Then pass the customer profile info instead of the opaqueData in the Create Subscription request.

Please let me know if this is the recommended solution or if there is a better solution. Thanks.

---

This error means Authorize.Net rejected the one-time-use payment token we sent them for the transaction. After they get that error message, they immediately try hitting 'Place Order' again, without changing any of their billing or payment info.

[blackwood821]

@worldmodern I ended up doing something similar. I require the user to create a payment profile before processing any charges. It made it much simpler.

[jamespslab]

---

@Campos369 wrote:

Mobdro

---

@blackwood821 wrote:

Hi,

I'm currently integrating Accept.js into my site to become PCI compliant. Here was my old server-side work flow:

Create new monthly subscription:

1. Authorize credit card for first month payment (send credit card info: number, exp date, etc.)
2. If authorization succeeds
   1. Create subscription (send credit card info: number, exp date, etc.) and start billing from the second month since the first month payment is handled now
   2. Capture previous authorization
3. If authorization fails
   1. Void authorization transaction (send credit card info: number, exp date, etc.)

Now I want to tweak this work flow so that I send the opaqueData (dataDescriptor and dataValue) in place of the card info. So the new work flow is now:

Create new monthly subscription:

1. Authorize credit card for first month payment (send opaqueData)
2. If authorization succeeds
   1. Create subscription (send opaqueData) and start billing from the second month since the first month payment is handled now
   2. Capture previous authorization
3. If authorization fails
   1. Void authorization transaction(send opaqueData)

Step 1 succeeds but step 2.1 fails with the response "Invalid OTS Token". I understand that this is because the dataValue token has already been processed in step 1 (the authorization). So my question is, how do I handle not sending the same dataValue in step 2.1 without sending card info since my server no longer receives that? Also, are neither the card info nor the opaqueData required for steps 2.2 and 3.1?

An option I'm considering:

1. Create a customer profile by setting the (createProfile parameter to true) in the authorization request (if it doesn't already default to true). Then pass the customer profile info instead of the opaqueData in the Create Subscription request.

Please let me know if this is the recommended solution or if there is a better solution. Thanks.

---

This error means Authorize.Net rejected the one-time-use payment token we sent them for the transaction. After they get that error message, they immediately try hitting 'Place Order' again, without changing any of their billing or payment info.

---

Thanks.