Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
page  <- 1234567891011121314151617181920 -> <- 1 .. 4 .. 20 ->
--
--
List results:
Search options:
Use \ before commas in usernames
He's back!
When do we get to see reruns?

Are you doing it next year? I wouldn't might doing a run if I have the money to travel.

I could do a Sonic 1 (race), Tomb Raider 1 and Goldeneye/Smash Bros Brawl/Street Fighter Multiplayer 
I don't think this is quite the right topic for planning the next marathon. This is about the administration stuff, eg handling donations and stuff.
Quote from Mystery:
Having a "donation shop" should definitely be practical. There are shop systems out there, and even if not, it should be easy to code. We just need to be able to hookup Paypal so we can be sure that the donations were made, then store the info into a database where we can pull information into nice looking statistical pages.
I don't know of any shop systems, though. No experience in that area.

EDIT:
I took a look at PayPal API at https://www.paypal.com/developer
It certainly looks feasible. You can use the API to transfer funds from a donator to a PayPal account (though the owner of the "app" or page or whatever must have a business account).
Now if anyone has any suggestions or experience on how to make a demo of this to test it, we could try making a server-side test donation app and see how it works.


Agreed on the feasibility of doing it, plus it could also make the commentator's job simpler, since he can just be presented with a queue of the most recent donations as they come in (no more missing earlier donations).  I don't really have the time to test anything out right now (currently in the middle of my second move this year), but once things settle down I should be able to take a look at it.  From the looks of it one just needs to set up a web-server that responds to HTTP requests from paypal, which would be pretty easy, I think the hardest part would be matching it up with the comments, but not at all impossible.  We'd end up re-implementing chip-in, but that doesn't seem like a bad thing.
Balls jerky
Hey man don't worry about time. We've got a whole year to hammer this thing out right?
1-Up!
Wanted to pop back in and say this thing was a HUGE help!  I manned it during one of the large donation spikes and while I agree it can be improved for next year, it was still really helpful, so props to you, SMK!
Edit history:
Mystery: 2011-01-15 11:30:16 am
Mystery: 2011-01-15 11:30:03 am
Mystery: 2011-01-15 11:29:34 am
I have managed to tame PayPal!

Take an especially good look at the last page. You can see the lot of information PayPal so happily provides us with. With this, we should be one step closer to realizing a web interface for donations.
Suggestions? Ideas?

Also, ideally, it would be nice to have a server to upload this to, so that everyone can try it.

Picture attached.
For those who can't view YT for one reason or another, here is the raw video: http://uploading.com/files/154aaa97/Marathon%2BDonation.mkv/

Attachment:
@dballin: A year can melt away very quickly if you don't pay attention

@Flip: If we're lucky, there will be a much smaller need in the 'manning' department next year

@Mystery: I can host html/php on my university's web space (i.e. where I was hosting my other code) so it should work.  If you could attach the source in a zip or something I'll put it up on my site.
Edit history:
Mystery: 2011-01-16 07:15:08 am
Mystery: 2011-01-15 03:11:08 pm
Source attached.
Btw, in order for it to work, you need to have a sandbox paypal account.
It's currently tailored to my sandbox id, so you'll need to use it to try it.
I don't know if it's such a good idea to post passwords publically, so I'll just PM it to anyone who asks.

EDIT: Archive contained empty files. Attachment removed. See reply below for new attachment.
The two files in the archive appear to be empty, can you resubmit them?
Not a walrus
Except it's not our paypal, it is (or was) PCF's paypal. I don't think we have access to that.
very good point. they would have to set up ipn or whatever on their account. i'm not sure we can expect them to do that. it may be better to write something to scrape chipin.
Edit history:
SMK: 2011-01-15 07:52:18 pm
But doesn't chipin do this already (that is, get payment notification even though it is being passed onto a seperate account)?  It must be possible to receive the payment notifications even if the payment is being forwarded to a third party.  I was hoping to look at Mystery's implementation to see how the page responses are handled.
Edit history:
nate: 2011-01-15 07:55:48 pm
that's a good point. you should get an http post body debugger (i *believe* firebug does it) and check what chipin is sending to paypal when the user hits the donate page at paypal. it's probably in one of those vars. here's a page i found helpful in the past:

https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_Appx_websitestandard_htmlvariables
Edit history:
Mystery: 2011-01-16 01:33:22 pm
Mystery: 2011-01-16 10:01:38 am
Mystery: 2011-01-16 08:29:29 am
Huh...
I guess 7zip doesn't link soft links.
OK then. Try 2.

The biggest problem with this is that the receiving account needs to set some settings.
First it must generate proper HTML button code and secondly it must set up payment data transfer and give us the token or whatever it's called.
None of it is particularly hard, however. I'm pretty sure you could convince them to do it.

Btw, rename test.php5 to index.php and paypal_return.php5 to paypal_return.php.

Now, there should be another issue we should discuss.
First off, should we let the user enter the donation details before or after the donation? Both have their advantages and disadvantages.
If we do it before, then we need to do some manual post request to forward to the paypal donation site (because we need to save the content of the forms by calling the script again).
This could be tricky. But it has the advantage of us being able to take advantage of IPN.

If we do it after, then we can't use IPN (because it's asynchronous). And we need the donator to return to out site in order to fill out the details. Kind of like what I did right now.
I don't think there's any big disadvantage to this, though. The only thing that might happen is some payment under review or something. But that could happen whether or not we use this approach...

EDIT:
Forgot I already have a place where I can upload files.
You can try it here: http://www.essentia.site88.net/sda/donation_test1/
You can get the passwords here: http://www.essentia.site88.net/sda/getpass.php

EDIT2:
Updated source. Fixes some stuff and makes it standard-compatible HTML.
Still can't upload new stuff to edited posts. Annoying.
Oh yeah, and no need to rename anything.
Attachment:
Edit history:
Mystery: 2011-01-16 01:33:40 pm
And so another reply because I can't attach to already posted replies... perhaps I should just delete them and merge them all into one post -_-
Anyway...

I did another test which you can see here: http://www.essentia.site88.net/sda/donation_test2/
Note that the old test is still available at http://www.essentia.site88.net/sda/donation_test1/

Attaching screenshots and new source.



Exoray
We might want to consider handling prizes differently the next time. With the current way things worked, people who donated for a goal/character name prior to a run starting weren't in on the game specific raffles for that game.
This would require that you would also be able to link bids to prize drawings in the app.
Edit history:
Mystery: 2011-01-16 02:03:13 pm
Mystery: 2011-01-16 02:00:49 pm
>>weren't in on the game specific raffles for that game.
Meaning they had no idea if what they donated for was feasible or not?

Also, looking at IPN, it seems that this might be more complicated than PDT. However, we might gain the added flexibility of checking for completeness, chargebacks, canceled or failed transfers, etc. Things that might happen after the paypal process was done and the donator redirected back to the site. So say that a donation was completed, but then there was a chargeback. We could delete the bid from our database and send an email to the donator.
Both IPN and PDT requires at least some settings be set in the receiving paypal account, though.

Of course, none of these techniques will help with refunds. But do we need that ability?
IPN is currently tricky for me to test. I'd need some way of remote debugging. The debugger should kick in when paypal tries to execute my script. Hmmm. This seems a pain :/
Exoray
No, meaning they had no chance at winning one of the game specific (non picture) prizes that required you to donate during the actual run.
Fucking Weeaboo
Well, I have no issue with that, as long as we have general prizes you can win for donating whenever.  It's an incentive to, you know, keep watching the marathon!
Edit history:
Mystery: 2011-01-16 03:06:35 pm
Quote from moooh:
No, meaning they had no chance at winning one of the game specific (non picture) prizes that required you to donate during the actual run.

Ah, I see. That could certainly be fixed.
I think the best idea is to simply make a list (or lists) of things you can donate for, which the donator can select and donate for.
At least, that is my opinion.
Edit history:
Arrow: 2011-01-16 03:10:36 pm
Now a hit show on the CW
Yeah, I think as long as we're more clear from the start (and having a dedicated prizes link that's easy to locate on the main page will go a long way towards that) about which prizes are available to any donor (the pictures) and which ones are only available for donations during that specific game (everything else), then people really won't have an excuse for not being able to donate for the prize they want. If they're not going to be able to log in for 10 seconds during a specific game that they really want a prize for, they can always have a friend donate for them, or whatever.

This may not be the right thread to discuss this, but I'd also be in favor of having a few $10 prizes next year. I think the $5 baseline was a good incentive, and is largely to thank for us raising over $50k this year. While I'm sure that a lot of the same people who donated would have been more than willing to spare an additional $5 for their donations, I don't want to risk alienating a lot of potential donors by having everything be a $10 baseline. But on the other hand, I think we can all agree that certain prizes (like the plushies and Sophia) would probably not have been affected at all by a $10 buy in, and could have potentially earned much more money than they did.
Edit history:
Mystery: 2011-01-16 03:43:17 pm
Maybe we could haxx0r up an admin interface for stuff like that. We got a lot of time, after all, and that stuff isn't particularly difficult once we get the basics down.
Still, I am thinking ahead too much. We haven't even decided if we're going to do this or not, or the details of how we're going to do it.
Edit history:
SMK: 2011-01-17 05:04:57 pm
SMK: 2011-01-17 05:04:40 pm
SMK: 2011-01-17 04:45:12 pm
http://tutorialzine.com/2010/05/donation-center-php-mysql-paypal-api/

This looks suspiciously like what we're looking for.  I was only able to look at it briefly, I'll take a more in-depth look when I have some time tomorrow, but this may give some more ideas on how to implement what we're trying to do.

**EDIT**

Okay, so, looking over this example, a couple of things I noticed:

1) There is no need to use that authorization token at all.  I set up a sandbox test on my own machine and it passed just fine without it.  All we'll need is their paypal e-mail id (and it doesn't even have to be a business account, any account can receive donations).

2) We can receive IPN on their transactions even if its not our account.  All you need to do is add the following html variable when performing the POST to paypal:  notify_url=*the url with our IPN handler*. We can then link up the transaction IDs later to link their donation to their comments and stuff, regardless of whether they input their comments/other stuff before or after (after makes it more 'donation-y', before makes it more 'shop-y').

With that in mind, I don't really see any reason not to go ahead with this.  The only unknown was paypal and their validation stuff, and as I said, that isn't necessary to do this.

Any objections Lady?
Edit history:
Mystery: 2011-01-18 04:36:11 am
Mystery: 2011-01-18 04:35:50 am
Mystery: 2011-01-18 04:24:00 am
I haven't had time to look it, though I sort of understand how it works. I know how IPN works, though it seems that it would be better if they input the details before donating, to see how much they have to bid and stuff.
Also, how about the returning after the donation? We cannot control the return URL with a variable. Are we going to ask the charity to redirect them back to the site?
And then finally, should we have the donator enter tails before or after? After can be trickier, and require that the donator is returned to the site.
Before is simpler since we have full control and can simply tag something as done when we get notification that the payment was done.

EDIT: Took a look at some of the code and it seems we can set a page for paypal to redirect back to? If that's true, then that would be awesome. Let me test that sometime.
EDIT2: OK, so having had a look at it, I understand what it does, and it seems fine. The only thing that worries me now is efficiency. The IPN basically stores the information into the database only, which means that the thankyou page needs to poll the database to get the info of the new donation.

Anyway, I'm not sure how much resources it would suck to have 1000+ people all viewing the donation page and donations coming in at the same time. Will it be okay to just poll the database for information everytime the user views a page, and especially after making a donation? If so, it should make things easy.

We should test this. I have a few more things I'm uncertain about, especially people donating simultaneously for the same thing.
If it works, then we should be ready to go on to building the whole donation framework around it.
Edit history:
SMK: 2011-01-18 02:09:10 pm
The return page is set by one of the variables that you POST to paypal (I believe the variable is "return", and you set it to the URL).  That URL itself will receive basically all the same information that the IPN one receives (i.e. transaction ID, donor name, amount, etc); the only reason we need to do the IPN is to get confirmation that the payment actually went through.  The thankyou page shouldn't need to poll the db at all (in fact, the thankyou page will typically come up before the IPN itself goes through, so it will generally be the first to write into the db).

That being said, you shouldn't be concerned about efficiency of access; most sites rebuild many of their pages from a database all the time, and furthermore, the amount of information we're querying is completely insignificant compared to the fact that we're already streaming audio/video as well. 

As for simultaneous donations?  I'm not quite clear what your concern is.  Do you mean if 2 people want to add suggestions for a certain bid at the same time?  I think that we'll need to manually verify all user submitted ideas first anyways.