[Transaction] Several 500 Internal Server Errors

[steeffeen]

the issue about

Code: Select all

isPaid($id)

is quite annoying because you can't build an own payment system with that... as you can't be sure whether a player payed the price or not

p.s. yey third post in a row, sorry

[magnetik]

According to the logs theses transactions does not exists.

If an exception is thrown the transaction must have not been paid.

[steeffeen]

According to the logs theses transactions does not exists.
If an exception is thrown the transaction must have not been paid.

thanks for the response

i can gladly post screenshots (not now, i'm not at home) of my ingame mails showing that i've received donations with the following (failing) ids:
1179527, 1178036, 1155389, 1155385, 1150998, 1150997, 1143838
the rest hasn't been paid

(background: i'm saving all created transactions and check them for an overall balance, the listed ids cause '500' errors even though i got a mail with planets for them)

//Edit: btw, how can transaction "not exist" when the id is counting up continuously?

[magnetik]

Paid transaction are deleted every day.

[steeffeen]

oh.. okay
is that really needed? ^^

[magnetik]

I don't see much case where a transaction can be created a not paid after a few seconds?

There are A LOT of transactions so it's required to avoid overloading our systems.

[The_Big_Boo]

If someone "plays" with your application to create then cancel many transactions, you risk hitting up the API request limit faster. But by keeping the transaction id, if the player don't pay it, you can still propose him the same one next time (considering it's not too old, let's say a few hours) and save some requests.

This is done in CompetitionManager for instance, where API limit can already be an issue without transactions.

[steeffeen]

But by keeping the transaction id, if the player don't pay it, you can still propose him the same one next time (considering it's not too old, let's say a few hours) and save some requests.

and how should i know that he didn't pay the old transaction without making a request?
it doesn't have to do something with request count if you ask me

i understand that the need of decreasing the system load as much as possible, it's just unfortunate for maintaining the balance..

[steeffeen]

okay i've just checked back and the other failing ids which i thought haven't been paid are paid as well ^.^
(i thought the error 500 isn't only happening on paid transactions)

so can i be sure that unpaid transaction won't be deleted after a short time? so i can assume that failing ids have been paid

[The_Big_Boo]

My answer was actually for magnetik asking a case where a transaction can be created but not paid immediately.

and how should i know that he didn't pay the old transaction without making a request?

Here's how it works:

• you create a transaction and propose it to the user
• whatever he does, you check the transaction status
  • if it's paid... well, it's paid
  • else, you keep it so you won't have to create the same transaction again (same amount, same payer, etc.), you won't need to check again its status (you've just done it) thus you save one request

Btw, I'm not sure about it but iirc, ManiaLoto also uses this principle (or at least a similar one).