IAP Ticket Verification API not working in production mode

[derconny]

I've send this question to developer.support@nokia.com but only got a link to the FAQ and got asked to post my question here again. So here it goes:

Dear Developer Support Team,

we're using Symbian/Qt IAP with our own backend server. There we use the Ticket Verification API to test the purchase tickets. We directly pass the purchase ticket from our app to the backend server and from there to Nokia IAP servers. We don't extract or manipulate the contents of the purchase ticket.

If we're using the app in online testing mode everything works fine. The Ticket Verification API accepts our POST request and we receive a valid response. But if we remove the "TEST_MODE.TXT" file in order to use the IAP API in production mode, the Ticket Verification API returns "HTTP 400 - Bad Request".

The code paths in our app and the backend server are exactly the same in both situations. The only difference is the existence of the TEST_MODE.TXT file.

So my question is: Is there anything else we need to do in order to use the Ticket Verification API in production mode? E.g. must our app be published? Or do we have to use a different server address?

Here is one transaction-ID that shows this problem: 218558590949

If you need more information please don't hesitate to contact me.

Best Regards,
Cornelius Hald

*EDIT*
Please also not that the money has been successfully withdrawn from my Credit Card.

[derconny]

The FAQ states to contact the support again via mail providing the following information. I've done that now, so lets see what happens...

- Nokia Store Purchase OK? (Yes/No)
- Time of IAP transaction (Time/Day/Month/Year)
- Time zone
- Nokia Store account
- IAP resource that you are purchasing
- IMEI
- Operator
- Works with Credit card? (Yes/No)
- Works with Operator Billing? (Yes/No)
- Error message or behavior observed

[Maveric]

Hi there, derconny

Hope your case will get handled as soon as possible, as you have indeed done all there is to be done.

I will be following this case personally.

Best Regards,
Marko

[derconny]

Thank you! I'm already in contact with one of your colleagues via email and I'm currently rechecking everything using working and not-working tickets curl, etc... We should know more soon

[Maveric]

Hello!

Sounds great, I am happy you got connected and could continue without any further delays!

Keep up the good work there! =)

Have a great day!

Best,
Marko

[derconny]

Hi again,

I'm back with more information but no solution yet unfortunately...

I did a production payment and a testing payment of the same in-app item and captured the tickets returned by the IAP API. It turned out that if I use the Purchase Verification Request Test Tool both tickets (testing and production) verify just fine.

However if I try to verify them using python or curl I still get an error but only with the production ticket. Here are the tickets for you to reproduce this issue.

Testing ticket

content=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PurchaseVerificationRequest xmlns="http://payment.ovi.com/iap">
<Binary>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/PjxQdXJjaGFzZVRpY2tldCBzaWduYXR1cmU9ImE4NGE0YTQzY2NkYjhjNzViZGU5M2FkMzkzNzBjNTIxZWI3NjU0ZjYiIGltc2k9IjY2YmIwMjBhZmUwNGUwYmE5YjJhMzk0NTc5YzU0OGM4NmExNjkxNmJlZWViZmYwZjVmOGYzNGE1ZDBhOGZmY2ZlYTE5YTY4YmMzNmMxMzYxM2I3OTFjMmNiNDgwMTBhMTEwYTNjMjEzM2JlMjY3NDBlOTcyZjEwZjNkODI0NjVmIiBpbWVpPSJmNzY4OTdhNWEzNTcxZDc5NWZmODIwYzg2YTZjNmIyNzM5N2MwODg2ZGEzZTU1YzE4Nzc5NzMxZmE4ZTBkNjZkMDcyODNhMjQ3MTJhY2ZkMDc1YWQ3MWZlZGJlYzk3YzBlOTcyMjMyZTNjYjEwOGEwZjRkYWI2NTFiYWY2NDcyMCIgYWNjb3VudElkPSJmZjIwNjBkNDAxY2IxOTlhYjMwYWViNjQ2ZDUzMDZhZTg4ODYzNmU0YjlmYWQyN2YwMDU1ZWJkYWQ1YjBiYWQwZDhmNzc5NjMzNTk0NGQ5ODdjYzhiOTNhOTI3Nzg5MjdlNjE0NmY4M2ZmMmU5MmFmNGEwZDdkNGQwMTVhZWYzNCIgcHJvZHVjdElkPSI4MDYwNjUiIGFwcGxpY2F0aW9uSWQ9IjAwMDAwMCIgdHJhbnNhY3Rpb25UaW1lPSIyMDEyLTAyLTE1VDEwOjA5OjQ0LjAwMFoiIHRyYW5zYWN0aW9uSWQ9IlRFU1QzOTc0NTQ4NjY3NTIiIHhtbG5zPSJodHRwOi8vcGF5bWVudC5vdmkuY29tL2lhcCIvPg==</Binary>
</PurchaseVerificationRequest>

Production ticket

content=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PurchaseVerificationRequest xmlns="http://payment.ovi.com/iap">
<Binary>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/PjxQdXJjaGFzZVRpY2tldCBzaWduYXR1cmU9IjFlZDhjZTkyNTk3MWNlNTE1NzJlZWU2ZjA3YWJlODA2ODYxN2E1MWMiIGltc2k9IjY2YmIwMjBhZmUwNGUwYmE5YjJhMzk0NTc5YzU0OGM4NmExNjkxNmJlZWViZmYwZjVmOGYzNGE1ZDBhOGZmY2ZlYTE5YTY4YmMzNmMxMzYxM2I3OTFjMmNiNDgwMTBhMTEwYTNjMjEzM2JlMjY3NDBlOTcyZjEwZjNkODI0NjVmIiBpbWVpPSJmNzY4OTdhNWEzNTcxZDc5NWZmODIwYzg2YTZjNmIyNzM5N2MwODg2ZGEzZTU1YzE4Nzc5NzMxZmE4ZTBkNjZkMDcyODNhMjQ3MTJhY2ZkMDc1YWQ3MWZlZGJlYzk3YzBlOTcyMjMyZTNjYjEwOGEwZjRkYWI2NTFiYWY2NDcyMCIgYWNjb3VudElkPSJmZjIwNjBkNDAxY2IxOTlhYjMwYWViNjQ2ZDUzMDZhZTg4ODYzNmU0YjlmYWQyN2YwMDU1ZWJkYWQ1YjBiYWQwZDhmNzc5NjMzNTk0NGQ5ODdjYzhiOTNhOTI3Nzg5MjdlNjE0NmY4M2ZmMmU5MmFmNGEwZDdkNGQwMTVhZWYzNCIgcHJvZHVjdElkPSI4MDYwNjUiIGFwcGxpY2F0aW9uSWQ9IjAwMDAwMCIgdHJhbnNhY3Rpb25UaW1lPSIyMDEyLTAyLTE1VDA5OjM2OjMyLjAwMFoiIHRyYW5zYWN0aW9uSWQ9IjIwNzMzODI4MDMyMSIgeG1sbnM9Imh0dHA6Ly9wYXltZW50Lm92aS5jb20vaWFwIi8+</Binary>
</PurchaseVerificationRequest>

To send those tickets to the Ticket Verification API I save them as files and then execute the following curl command on a shell.

curl "https://payment.ovi.com/iap/1.0/purchases/verify?method=GET" --data @something.ticket -w "\nCode: %{http_code}\n"

Here is what I get using the testing ticket.

[conny@t61 ~]$ curl "https://payment.ovi.com/iap/1.0/purchases/verify?method=GET" --data @testing.ticket -w "\nCode: %{http_code}\n"
<?xml version="1.0" encoding="UTF-8" standalone="yes"?><PurchaseVerificationResponse result="OK" xmlns="http://payment.ovi.com/iap"/>
Code: 200

And here with the production ticket.

[conny@t61 ~]$ curl "https://payment.ovi.com/iap/1.0/purchases/verify?method=GET" --data @production.ticket -w "\nCode: %{http_code}\n"
Server Error: 4f2587a6-831a-4779-914f-f17b8589a259
Code: 400

I've checked the JavaScript/HTML source code of the "Purchase Verification Request Test Tool" but cannot find any significant differences. But obviously it is doing something different because the result is different :/

I guess there might be something wrong with the encoding of the data before sending it to the API, but I'm stuck and would really appreciate your help.

Thanks!
Cornelius

[izinin]

Hi Cornelius

in case you are missing my messages your mailbox (e.g. --- due to mailbox extremely limit size ) -- i need to check TEXT_MODE.txt file content

My impression is simulation mode you use alters data roundtrip such way that PTV functionality is not involved and thus the problem is not seen. Then you try to check the tickets manually with PTV and see that one of the checking fails. From the other hand the both checking succeed with PTV test tool. So i conlude that our problem is how to use curl in PTV.

Please comment my assumption to go further.

Regards,
Igor


Regards

[derconny]

Hi Igor,

I've already answered both of your private messages. Anyways here is the content of the TEXT_MODE.txt file.

[testserver]
testMode=purchase

I also think that something with *my* code is wrong because checking the ticket manually works. However I really do not understand why my code works perfectly fine (not a single failure) with testing tickets. You can verify that using curl and the testing ticket. It will work.

Also I'm 100% certain that I'm using the same code paths on our server for both testing and production purchases. I log the ticket and the PTV reply to the database so I'm able to verify that.

Thanks,
Cornelius

[derconny]

For the sake of completeness here is the code I'm running on our backend server to validate a ticket. The behavior is exactly the same as when using curl. Works with testing ticket, fails with production ticket.

Maybe it helps with diagnosing the problem.

def nokia_ticket_is_valid(ticket):
    """ Sends the ticket to Nokia to see if it is valid """
    validationRequest  = '<?xml version="1.0" encoding="UTF-8" standalone="yes"?>\n' 
    validationRequest += '<PurchaseVerificationRequest xmlns="http://payment.ovi.com/iap">\n'
    validationRequest += '<Binary>'
    validationRequest += ticket
    validationRequest += '</Binary>\n'
    validationRequest += '</PurchaseVerificationRequest>'
    
    headers = {'Content-type': 'application/x-www-form-urlencoded', 'charset': 'UTF-8'}
    body = 'content=' + validationRequest
    
    conn = httplib.HTTPSConnection('payment.ovi.com')
    conn.request('POST',
                 'https://payment.ovi.com/iap/1.0/purchases/verify?method=GET',
                 body,
                 headers)
    response = conn.getresponse()
    
    if response.status == 200:
        # Check data (must contain OK)
        xml_data = response.read()
        root_element = fromstring(xml_data)
        result = root_element.attrib.get("result")

        if result == 'OK':
            return True, result
        else:
            return False, result
    else:
        return False, 'Http response ' + str(response.status)

[izinin]

Hi Cornelius,

Purchase ticket 'test' does not contain symbol '+' but 'production' -- does. The point is : when you compose request with

conn.request('POST',
                 'https://payment.ovi.com/iap/1.0/purchases/verify?method=GET',
                 body,
                 headers)

in body part symbol '+' is translated to ' ' according to http standard. Do you have any chance to capture tcp traffic and check if this is the reason the problem?

if base64 form you send is corrupted it will result with server error -- no meaningful error message back

[derconny]

Hi Igor,

that might be a possibility. I'll try to check that but sniffing the traffic probably won't work because it is SSL encrypted. I'll keep you updated.

Thanks,
Cornelius

[derconny]

Hi Igor,

as I can't look into the communication because of SSL, I did something else. With curl I've send the data to my own server instead of payment.ovi.com and dumped the POST data there. The data is the same as the input data. The "+" is still there and everything runs smoothly. If I diff the local file with the server file, the only difference is the stripped line-breaks on the server.

Best Regards,
Cornelius

[izinin]

Hi Cornelius,

At least replacing '+' with '%2B' in your "bad ticket" works with curl. So i suggest you to make fix blindly in your code and check whether the problem is gone.

"fixed" ticked:

content=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PurchaseVerificationRequest xmlns="http://payment.ovi.com/iap">
<Binary>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/PjxQdXJjaGFzZVRpY2tldCBzaWduYXR1cmU9IjFlZDhjZTkyNTk3MWNlNTE1NzJlZWU2ZjA3YWJlODA2ODYxN2E1MWMiIGltc2k9IjY2YmIwMjBhZmUwNGUwYmE5YjJhMzk0NTc5YzU0OGM4NmExNjkxNmJlZWViZmYwZjVmOGYzNGE1ZDBhOGZmY2ZlYTE5YTY4YmMzNmMxMzYxM2I3OTFjMmNiNDgwMTBhMTEwYTNjMjEzM2JlMjY3NDBlOTcyZjEwZjNkODI0NjVmIiBpbWVpPSJmNzY4OTdhNWEzNTcxZDc5NWZmODIwYzg2YTZjNmIyNzM5N2MwODg2ZGEzZTU1YzE4Nzc5NzMxZmE4ZTBkNjZkMDcyODNhMjQ3MTJhY2ZkMDc1YWQ3MWZlZGJlYzk3YzBlOTcyMjMyZTNjYjEwOGEwZjRkYWI2NTFiYWY2NDcyMCIgYWNjb3VudElkPSJmZjIwNjBkNDAxY2IxOTlhYjMwYWViNjQ2ZDUzMDZhZTg4ODYzNmU0YjlmYWQyN2YwMDU1ZWJkYWQ1YjBiYWQwZDhmNzc5NjMzNTk0NGQ5ODdjYzhiOTNhOTI3Nzg5MjdlNjE0NmY4M2ZmMmU5MmFmNGEwZDdkNGQwMTVhZWYzNCIgcHJvZHVjdElkPSI4MDYwNjUiIGFwcGxpY2F0aW9uSWQ9IjAwMDAwMCIgdHJhbnNhY3Rpb25UaW1lPSIyMDEyLTAyLTE1VDA5OjM2OjMyLjAwMFoiIHRyYW5zYWN0aW9uSWQ9IjIwNzMzODI4MDMyMSIgeG1sbnM9Imh0dHA6Ly9wYXltZW50Lm92aS5jb20vaWFwIi8%2B</Binary>
</PurchaseVerificationRequest>

Regards,
Igor

[derconny]

Hi Igor,

sorry for the spam but I did some more tests and I think I might have spoken too soon. The "server" I'm currently testing against is a simple Django app. What I first did was duping the *raw* POST data like this:

# Prints the ticket including the trailing plus
print request.raw_post_data

The raw POST data really contains the "+". However if I access the value of the "content" key, the plus is replaced by a space.

# Print the ticket without the trailing plus
print request.POST['content']

So I think your theory about the "+" sign is a very good one I'll do some further testing and report back.

Thanks a lot for your input, this is very valuable!
Cornelius

[derconny]

Hi Igor,

you've been faster than me and you have the complete solution already -- awesome

You're absolutely right. If I do it like this, the raw POST data shows it as "%2B" but accessing the POST array gives me a "+". Also sending the ticket to Nokia like this returns "OK". So the solution is to first urlencode the ticket before sending it.

Thanks a lot for your help Igor, this was quite hard to debug!

I hope this has been the last time I had to bother you... Have a nice day
Cornelius

*edit*
Just a small addition: I've checked all tickets I've received so far and all of the 'production' tickets have a plus in them while non of the 'testing' ticket have it. This might be a coincidence only happening to me. But maybe it's worth documenting the urlencoding step in the official documentation. It is confusing if during testing everything works but then in 'real life' doesn't work anymore. One might get the impression that it has something to do with 'production' vs. 'testing' and not with the own code. Like my example showed

Hi Cornelius,

At least replacing '+' with '%2B' in your "bad ticket" works with curl. So i suggest you to make fix blindly in your code and check whether the problem is gone.

"fixed" ticked:

content=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PurchaseVerificationRequest xmlns="http://payment.ovi.com/iap">
<Binary>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/PjxQdXJjaGFzZVRpY2tldCBzaWduYXR1cmU9IjFlZDhjZTkyNTk3MWNlNTE1NzJlZWU2ZjA3YWJlODA2ODYxN2E1MWMiIGltc2k9IjY2YmIwMjBhZmUwNGUwYmE5YjJhMzk0NTc5YzU0OGM4NmExNjkxNmJlZWViZmYwZjVmOGYzNGE1ZDBhOGZmY2ZlYTE5YTY4YmMzNmMxMzYxM2I3OTFjMmNiNDgwMTBhMTEwYTNjMjEzM2JlMjY3NDBlOTcyZjEwZjNkODI0NjVmIiBpbWVpPSJmNzY4OTdhNWEzNTcxZDc5NWZmODIwYzg2YTZjNmIyNzM5N2MwODg2ZGEzZTU1YzE4Nzc5NzMxZmE4ZTBkNjZkMDcyODNhMjQ3MTJhY2ZkMDc1YWQ3MWZlZGJlYzk3YzBlOTcyMjMyZTNjYjEwOGEwZjRkYWI2NTFiYWY2NDcyMCIgYWNjb3VudElkPSJmZjIwNjBkNDAxY2IxOTlhYjMwYWViNjQ2ZDUzMDZhZTg4ODYzNmU0YjlmYWQyN2YwMDU1ZWJkYWQ1YjBiYWQwZDhmNzc5NjMzNTk0NGQ5ODdjYzhiOTNhOTI3Nzg5MjdlNjE0NmY4M2ZmMmU5MmFmNGEwZDdkNGQwMTVhZWYzNCIgcHJvZHVjdElkPSI4MDYwNjUiIGFwcGxpY2F0aW9uSWQ9IjAwMDAwMCIgdHJhbnNhY3Rpb25UaW1lPSIyMDEyLTAyLTE1VDA5OjM2OjMyLjAwMFoiIHRyYW5zYWN0aW9uSWQ9IjIwNzMzODI4MDMyMSIgeG1sbnM9Imh0dHA6Ly9wYXltZW50Lm92aS5jb20vaWFwIi8%2B</Binary>
</PurchaseVerificationRequest>

Regards,
Igor