Is it time for CGC board marketplace sales to be reported to GPA?

[comicwiz]

how do services like auctionsniper manage to bid on eBay auctions with your account information?

 

Users give AuctionSniper their E-Bay username and password. Ah, so you're suggesting sellers give GPA their PayPal username and password. That could work. I wasn't closed to that, it just hadn't occurred to me. Would anyone be dissuaded by having to set up a "seller's account" with GPA by giving them your PayPal info?

 

I think this would have to be a form functioning externally of GPA. I was thinking more along the lines of an interface that would function on-the-fly with no stored values other than the transaction ID and a "valid" or "invalid" value (could be a numeric value of 0 or 1 when its indexed). Personally, I would prefer a validation setup that simply checks that the transaction id is valid without having to authenticate at the user level.

[innocuous]

Whoah!

 

My first time checking out this thread and you guys are really geeking out.

 

If CGC wants to spend the money, UBB can be modified so that the entire process is automated via board posts and PMs. But, perhaps this is getting a little too far ahead.

[fantastic_four]

Personally, I would prefer a validation setup that simply checks that the transaction id is valid without having to authenticate at the user level.

 

Checking the amount of the transaction seems preferrable, as it prevents sales from being reported as being above what they actually were, but it certainly would be easier if the interface you allude to existed. Do you have any reason to believe PayPal would implement such an interface?

[fantastic_four]

If CGC wants to spend the money, UBB can be modified so that the entire process is automated via board posts and PMs. But, perhaps this is getting a little too far ahead.

 

How does that work, exactly?

[innocuous]

Everything you have discussed is just programming. UBB is PHP. So, querying and posting to the various API's is simple. When selling, you use a simple "reporting" interface custom built into UBB where you identify yourself, the comic sold and price. CGC pays the dev bill.

[VintageComics]

You guys do realize that this is WAY more information than Ebay, Comiclink, Heritage or any other data source have ever supplied don't you?

[comicwiz]

Personally, I would prefer a validation setup that simply checks that the transaction id is valid without having to authenticate at the user level.

 

Checking the amount of the transaction seems preferrable, as it prevents sales from being reported as being above what they actually were, but it certainly would be easier if the interface you allude to existed. Do you have any reason to believe PayPal would implement such an interface?

 

This exists because some vendors (even those using open license cart software) are able to query based on transaction ID. Meaning, if you bought something from such a vendor and an issue arose, the vendor would simply need your your transaction ID to pull the order. I've seen some sites provide a self-serve component to buyers that allows them to query their orders from a transaction ID. I know it isn't a transaction ID that is generated by the cart because they specifcally ask buyers to reference their 17-digit PayPal transaction ID. This pulls the order reference, and typically this includes details about the item purchased and purchase amount.

 

How this all happens is that at the time something is purchased, the carts backend takes the values from the product and binds them with select PayPal orders values. Going back to the previous post, one way this can be achieved is you find a cart tool or PayPal button that you can work with to extract basic values like the amount paid and the unique transaction ID. Because the unique transaction ID is generated only upon a succesfful purchase, that gives us part of the solution. The other part is determining whether to factor into the equation account values like "Pending" or "Incomplete" which means the sellers has to wait until the payment clears to ship the book. This could impact the reporting aspect especially if the funds don't clear for any reason, the book is relisted, and you have a sales figure which doesn't reflect an actual sale. Nitpicking on something like that is probably unecessary because this currently must happen to some degree with auction results, but certainly something to think about if you intend to refinine this process to provide a more accurate reporting mechanism.

 

Think of it more like a merchant tool (code for a cart/PP button) which would be passed around and used via PM or right on the thread if you want to be efficient with sales. The code from the button would point to a form where you would have to enter the product description, payment amount, slab details (this is where you would need to make sure you abide by variable conventions to make sure the data can be interpreted by GPA). This could very well look like the Pay Now form on eBay before you are taken to PayPal's checkout. Once you're good with the values entered, you submit the form and it forwards you to PayPal's checkout (while the values from the form are sent to a desired database location). After payment, the PayPal page redirects you back to a thank-you/payment success page (this value is specified in the cart/PP code) which carries with it the transaction ID and binds it with the stored values from the form. The last part of this would be to syndicate the values residing in the database in a an XML feed format that GPA could access and use to populate into their database. With this design type, querying based on a transaction ID, is as I said in my earlier post, possible.

 

While I haven't gone as far as creating the XML feed component as described for this specific application, I can assure you that the functionality which I speak of has existed for many years and I have hand-coded this to work on several sites seamlessly with PayPal. Technically, it really isn't that complicated, although you would want to think through every aspect to ensure it makes sense for this specific application. I've got to run, and now that I've laid something out to start with, maybe you can build it. (thumbs u

[comicwiz]

You guys do realize that this is WAY more information than Ebay, Comiclink, Heritage or any other data source have ever supplied don't you?

 

This is a valid point Roy, however we really only need the metrics which are relevant to GPA's current reporting model, and expanding on it doesn't make sense unless GPA sees a benefit to expand its own reporting (i.e. page quality, date stamps, pressed... oops, did I say that out loud )

[VintageComics]

You guys do realize that this is WAY more information than Ebay, Comiclink, Heritage or any other data source have ever supplied don't you?

 

This is a valid point Roy, however we really only need the metrics which are relevant to GPA's current reporting model, and expanding on it doesn't make sense unless GPA sees a benefit to expand its own reporting (i.e. page quality, date stamps, pressed... oops, did I say that out loud )

 

The main reason I brought that point up is that you guys are on to something fantastic but I make many of my purchase and sales with checks and not Paypal to avoid fees. In this case (and likely in the majority of large transactions) all this stuff would not work.

 

I'd be interested in hearing thoughts regarding non paypal transactions such as check or money order.

 

R.

 

[comicwiz]

You guys do realize that this is WAY more information than Ebay, Comiclink, Heritage or any other data source have ever supplied don't you?

 

This is a valid point Roy, however we really only need the metrics which are relevant to GPA's current reporting model, and expanding on it doesn't make sense unless GPA sees a benefit to expand its own reporting (i.e. page quality, date stamps, pressed... oops, did I say that out loud )

 

The main reason I brought that point up is that you guys are on to something fantastic but I make many of my purchase and sales with checks and not Paypal to avoid fees. In this case (and likely in the majority of large transactions) all this stuff would not work.

 

I'd be interested in hearing thoughts regarding non paypal transactions such as check or money order.

 

R.

 

The form could have a drop down for payment method (PayPal, cheque, MO, cash) and if anything other than PP is selected, PP checkout is nullified and two new fields populate. The first is the buyers (board alias/name) and the second is a field requesting a hyperlink to the sales thread. The buyers board alias is a required field, and can be used as verification check. The second field can be made optional if it was a sale via PM. The drawback is that there won't be a PP unique transaction ID tied to the data but one can be autogenerated for the boards. The nice thing about this is the form still submits the data to be used by GPA, and perhaps it would be up to George's discretion whether he wants to verify the sale with the buyer on these boards via PM. In such a scenario, it remains a relatively anonymous sale except for the purpose of accurate reporting. Now I really have to run