PaymentOrder API

[jofmi]

Type of change

• [x] New feature (non-breaking change which adds functionality)

Description

• Adds CreatePaymentOrder and VerifyPaymentOrder handlers (see Swagger)
• Extends payment & order logic to create additional order entries on the backend (the frontend will only decide what items are bought by the user, the backend takes care of adding license buying, transaction fees, and transaction fee refunds)
• All prices and amounts are now handled in cents (integer) - A tip is an item with Price=1 and Quantity is the amount of the Tip
• Prices are always taken from the current price of the item

Checklist:

• [x] I have commented my code (or ChatGPT did), particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings, neither in my IDE nor in my browser
• [x] I have added tests that prove my fix is effective or that my feature works

[jofmi]

To make your whole concept work the frontend also has to send the parameter s back, which is the orderCode of VivaWallet and in your code declared as transactionID. I gave two suggestions in the comments below.

So the OrderCode is generated by the backend when it creates the Order and the TransactionID is generated by the Frontend when the payment is made?

[lebe1]

To make your whole concept work the frontend also has to send the parameter s back, which is the orderCode of VivaWallet and in your code declared as transactionID. I gave two suggestions in the comments below.

So the OrderCode is generated by the backend when it creates the Order and the TransactionID is generated by the Frontend when the payment is made?

Kind of true since all ID's are actually generated by VivaWallet but the backend receives the OrderCode and the frontend the TransactionID. I think it is more intuitive to also include VivaWallet's part in this process. First, the orderCode created by VivaWallet is received by the backend and the backend can therefore send the checkout url to the frontend. At this point VivaWallet has noticed that a payment will be made soon and lets a timeout run and other security stuff probably. When the checkout is finished VivaWallet creates a transactionID and redirects the user to the success page with transactionID and orderCode as param t and s. This transactionID can then be used for verification. This url is extracted by the frontend and for now only sends a POST-request for verification with the transactionID. To make our concept work, we need the transactionID for verification and the orderCode for the database queries. This diagram also helped me a lot to understand it.

[jofmi]

[jofmi]

ah yes, it should both be strings

[jofmi]

I still had the editor open so i fixed it @lebe1

[jofmi]

No, since I had trouble with the testing DB the handler isn't tested yet - so there's likely a few issues left. I think this one was connected to the router, tried to fix it

[lebe1]

No, since I had trouble with the testing DB the handler isn't tested yet - so there's likely a few issues left. I think this one was connected to the router, tried to fix it

Yes just figured this one also out on my own... Maybe I stop posting all my swagger and try solving it on my own before I annoy you again :upside_down_face:

[jofmi]

I would always look at the logs in docker, they give you a error trace with the line of code and everything

[jofmi]

I just realize how valuable the tests usually are to prevent this kind of gradual fixing. Sorry that you have to review without it being properly tested in this case! In any case, I think I found the error

[lebe1]

I just realize how valuable the tests usually are to prevent this kind of gradual fixing. Sorry that you have to review without it being properly tested in this case! In any case, I think I found the error

Yes looks good! And good point using docker logs! I just realized the specific line is meant by the numbers on the end of each log like "/app/database/queries.go:196"

[jofmi]

Yes, please add as a future todo then that the CreateAccount query needs a validation check that prevents these from being created a second time