Processing Developer Product Receipts For Donations

Help and Feedback Scripting Support
#13

These are currently the products

ignore the refund one

Donating 43263
  Prompting "400752821" for 10000 Robux purchase, 33263 Robux remaining
  Prompting "400752821" for 10000 Robux purchase, 23263 Robux remaining
  Prompting "400752821" for 10000 Robux purchase, 13263 Robux remaining
  Prompting "400752821" for 10000 Robux purchase, 3263 Robux remaining
  Prompting "400751866" for 2000 Robux purchase, 1263 Robux remaining
  Prompting "400751588" for 1000 Robux purchase, 263 Robux remaining
  Prompting "400749495" for 250 Robux purchase, 13 Robux remaining
  Prompting "400745223" for 10 Robux purchase, 3 Robux remaining
  Prompting "400744499" for 2 Robux purchase, 1 Robux remaining
  Prompting "400743916" for 1 Robux purchase, 0 Robux remaining
1 Like
#14

About the yielding part, is it going to wait for return before calling it again or will it be called consecutively even if it is waiting on a result?

#15

That’s a weird approach, won’t it prompt each one of those, and have to manually be accepted? You should just do tiers of payments. Eg. 10 robux, 50, 100, 250, 500, 800, 1000, 2500, 5000, 10000

#16

What do you mean? The user can choose exactly how much robux they would like to donate.

#17

No inputed amount, just different tiers that the player can select. Exactly how much will prompt up 10 different payment boxes (correct me if this does not happen), confusing the player as it would look like he/she is making multiple payments.

#18

You type an input and it would show beforehand what the payment would be as a list of orders. You click on the orders to make the payment

#19

890×667 13.6 KB

#20

As a fellow Dev, I would say that it’s ok to ask for money dude, we put months if not years into our games and Yes Donations are fine.

1 Like
#21

Do you happen to know if products that were successfully purchased are handled again?

#22

Successfully handled products are not handled again.

As for your last question, what I meant by making the functions yield was that you do something like this:

local completed, cancelled
-- do something to retrieve the current value or update values with a remote event or something
repeat wait() until completed
if cancelled then
    return NotProcessedYet -- shortened
else
    return PurchaseGranted
end
#23

What I do now is I have a list that fills up with receipts for the user.
The list is cleared when purchases fail or complete.
It checks the list to see if the product is part of the purchase sequence and if it was granted then it would grant the purchase

1 Like
#24

Yep, that’s fine, my issue is with returning NotProceessed yet. As I said, unless the server gets sent information by the client real quick, NotProcessedYet will be returned – but if it is the last purchase, then the callback will not update the state to PurchaseGranted (as even if the client makes the decision to go forward with the purchase, the server won’t get updated in time before the final ProcessReceipt callback runs).

#25

Yes but the callback is continuously called when they are prompted and buy so when the final purchase is made it will return as processed

#26

How often is it continually called, though?

It is likely they will leave as soon as they are done (therefore closing the server) which means the purchases may not be granted in time.

I’ve got no idea about the frequency so I guess I’ll leave it at that. Do what you think is best :wink:

#27

it is called multiple times when they buy an item

#28

Yes but what is the frequency of those calls? Because if it is low (if they aren’t called very often) the donator could leave the server (making it shutdown automatically) and as a result the purchases may not get processed within 3 days.

Imagine a car that beeps every five minutes while being driven. When the person gets out of the car, the beeping stops. The beeping has a fairly low frequency, as it happens once every 5 minutes. If it had a higher frequency, it might happen once every 5 seconds. The beeping is the ProcessReceipt callback being fired, and the car is the server. The callback can only be fired when the car (server) is running, but it needs meet a “quota” of beeps after the person stops driving (before the person gets out of the car, stopping the beeps entirely). Gtg but that’s the message I’m trying to get across.

#29

No it just runs everything at the same time

#30

Yes but I’m talking about what happens to a single purchase if NotProcessedYet is returned.

The player may leave the game during the interval between all of their purchases being accepted (by the player) and the next ProcessReceipt call.

If they are the only one in the server, the server may shutdown before the purchases get processed.

#31

No because they run really rapidly and all data is saved and purchases handled before game shuts down (via bindtoclose)

1 Like
#32

Instead of giving users the freedom of picking random numbers and then making them but dev products until they hit that price, couldn’t you just make a list of all products, and let them buy as much as they’d like from that list so that this issue doesn’t exist.

1 Like