User story
Annie from Adelaide Exchange went on holiday and agreed that the accommodation should be paid in local money to Brian from Brisbane exchange.
Ben logs on and goes to the external payment form, where he chooses Adelaide from a list of participating exchanges in the network. He knows Annie's id already and enters
- '3 nights accommodation'
- 30 Brisbane Barterdollars
- (towards himself)
- AnnieID
The software has obtained the list of participating exchanges through a simple request to a central authority (later this might be done peer-to-peer, but that's more complex). When Brian hits go, Brisbane first checks the validity of the transaction i.e. can Brian afford it, can the balancing account afford it, etc. Then Brisbane sends Adelaide the following information over http.
- New transaction with AnnieID
- From BrianID
- of Brisbane
- direction: incoming (i.e. towards the starter of the transaction)
- for '3 nights accommodation'
- payment 300 minutes (because time is the common denominator in this system)
Adelaide checks the validity of the transaction according to it's own criteria, and replies with OK or an error message. Brian's page reloads and if the transaction hasn't gone through he knows why.
API
The transaction is initiated with a url of the format:
https://www.yourdomain.com/mmouse/pay/dduck/23/services%20rendered
where
argument 1: source userid
argument 2: transaction_type = pay, claim
argument 3: destination userid
argument 4: quantity in base currency
argument 5: description of transaction
- OK - transaction confirmed
- This would exceed the balance limits of the user
- This would exceed the balance limits of the exchange
- Only claims allowed in this system
- Only payments allowed in this system
(This would be complicated if the second exchange had multiple currencies installed, more so if it had different currencies on different networks, but since no real world examples of this exist, I'm happy to live with this limitation for version 1.0
Comments