Market 3rd Party Receipts for External Verification

Discussion, Feedback, and Technical Support for the Timekoin Market hosted at timekoin.com
Post Reply
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Market 3rd Party Receipts for External Verification

Post by KnightMB »

The Market now has the ability to use a Receipt ID for every transaction to be used (if desired) by the Member for external verification. The purpose of this is to help protect buyer or seller if some dispute happens outside of the Market place.

Classic example, Paypal :shock:

You sell someone Timekoins in exchange they send you a Paypal payment. All goes well until about a day or week later, Paypal reverses the transaction. Seems that buyer called Paypal (or web form) and complained they never got their Timekoins. So by default, Paypal reverses the transaction and will contact you "the seller" for information. What always gets (screws) people when dealing with Paypal (or others like it) is they ask for some type of confirmation of delivery. Unfortunately, they won't take the time to load up the TK client and see for them-self by examining the transaction history of the keys involved, etc.

Instead they want some 3rd party verification like delivery confirmation if it was a physical item or receipt for payment. Since Timekoin does not spit out receipts (or any digital currency for that matter), you have no way to prove your case. To fill this "where's the receipt" gap, each completed transaction gets a unique Receipt ID that can be verified against the market externally without needing an account to login, etc. Each Receipt ID is in the completed transaction details at the bottom with an easy to click link that can be copied/pasted to where it needs for others to examine the receipt.

The hopes of this is to better protect buyers or sellers from reverse charge scamming when there is no way to prove payment when dealing with digital currencies like Timekoin (or any for that matter). It is not 100% bullet proof, but it does offer a 3rd party, unbiased assistance to members if they run into a situation such as this. The information includes all details of the transaction, so these remain private as long as you don't give away your Receipt ID.

Some examples I did to show what information is available (with the right Receipt ID) if needed.
Example 1
https://timekoin.com/market/receipts.ph ... HLKF35UYTM

Example 2
https://timekoin.com/market/receipts.ph ... 78KF52K7X5
User avatar
funnow
Posts: 157
Joined: Mon Jun 25, 2012 1:39 pm

Re: Market 3rd Party Receipts for External Verification

Post by funnow »

PayPal? Better OKpay! PP Is not crypto users friendly.
warmach
Posts: 404
Joined: Thu Jun 21, 2012 5:18 pm

Re: Market 3rd Party Receipts for External Verification

Post by warmach »

KnightMB wrote:
Some examples I did to show what information is available (with the right Receipt ID) if needed.
Example 1
https://timekoin.com/market/receipts.ph ... HLKF35UYTM

Example 2
https://timekoin.com/market/receipts.ph ... 78KF52K7X5
Could you make the user login before viewing this? The private messages will probably contain email addresses and mailing addresses. While I don't expect anyone to "guess" the receipt ID, why take the chance that this information be exposed when you can require them to login. You could then log who actually views this receipt for auditing purposes.
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Market 3rd Party Receipts for External Verification

Post by KnightMB »

funnow wrote:PayPal? Better OKpay! PP Is not crypto users friendly.
Certainly true, a google search of full of horror stories with Paypal. I'll have to look at OKpay, never tried them myself. :D
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Market 3rd Party Receipts for External Verification

Post by KnightMB »

warmach wrote:Could you make the user login before viewing this? The private messages will probably contain email addresses and mailing addresses. While I don't expect anyone to "guess" the receipt ID, why take the chance that this information be exposed when you can require them to login. You could then log who actually views this receipt for auditing purposes.
Both users that are part of the receipt or just anyone with a market account (to filter out google search,etc) ?
User avatar
koinmaster
Posts: 357
Joined: Mon Jun 18, 2012 8:07 pm

Re: Market 3rd Party Receipts for External Verification

Post by koinmaster »

How about using the account id as another part of the url? This way, the chance that someone is going to guess the right receipt id and the account id at the same time are just as impossibility remote and will not require a login to function. I see the concern of privacy, but I also see the benefit of this because it does allow someone to present proof that a trade did take place if the proof is required such as the paypal dispute example knightmb wrote.
KnightMB wrote:
warmach wrote:Could you make the user login before viewing this? The private messages will probably contain email addresses and mailing addresses. While I don't expect anyone to "guess" the receipt ID, why take the chance that this information be exposed when you can require them to login. You could then log who actually views this receipt for auditing purposes.
Both users that are part of the receipt or just anyone with a market account (to filter out google search,etc) ?
User avatar
KnightMB
Site Admin
Posts: 1019
Joined: Thu Feb 23, 2012 5:03 pm

Re: Market 3rd Party Receipts for External Verification

Post by KnightMB »

It is still kind of a catch, if you make a login or key required, then any external party that needs to view the information has to create an account first, which means needing a valid TK address, which means they might or might not do it. If I use the account ID, it would be just another layer, it could work, at least that way there would be a way to track who is viewing the receipt (the buyer link vs the seller link for example), would that be important though?
Post Reply