Different response formats for the same /payment api using different CallId and apiKey

Solved! Go to solution
jaxx303
Regular Visitor

Different response formats for the same /payment api using different CallId and apiKey

I'm using API:  https://sandbox.secure.checkout.visa.com/wallet-services-web/payment/data/4762xxxxxxxx7302?apikey=xx...

 

I am getting two different response formats when using different CallId and apiKey. 

One response contains the encKey and encPaymentData fields, while the other response has completely different data like externalClientId, userName, userEmail which is all in the clear.  

Any idea what causes this?  

4 REPLIES 4
jaxx303
Regular Visitor

Re: Different response formats for the same /payment api using different CallId and apiKey

After looking at the API Response more, it looks like it's the same response, with just different fields populated.  What could be different about the CallId that allows the encKey and encPaymentData to be returned on one and not another?

DianaTran-Yee
Visa Developer Support Specialist

Re: Different response formats for the same /payment api using different CallId and apiKey

Hi @jaxx303,

 

Which API product your query relates to? For a list of our API products, please visit our API Browser page here: https://developer.visa.com/apibrowser 




Thanks,

Diana



Was your question answered? Don't forget to click on "Accept as Solution" to help other devs find the answer to the same question.

jaxx303
Regular Visitor

Re: Different response formats for the same /payment api using different CallId and apiKey

My question is regarding the Visa Checkout API, and what determines if encKey and encPaymentData is returned in the response.  
I looked at the openApi file, but I think I need more details regarding the field descriptions or specific responses types. 

jaxx303
Regular Visitor

Re: Different response formats for the same /payment api using different CallId and apiKey

Disregard, I found the VisaCheckoutIntegrationGuideV1901.pdf document, which has the additional details I needed.  Thanks