Question re POS tutorial

Hi,

I was referencing the POS tutorial in the Algorand Developer Resources. Creating a Point-of-Sale Application with the Algorand Blockchain | Algorand Developer Portal

So my understanding is that the tutorial describes the flow from the POS app (such as a eCommerce website) to Payment Gateway (the server handling/verifying payment) to client wallet. The solution calls for an unsigned transaction to be generated from POS app, goes through the payment gateway, then passed to the client wallet, which sends the signed transaction back to the payment gateway to be broadcasted.

Assuming these passes are API calls (such as post requests from the wallet to the gateway),

  1. why can’t the client wallet directly submit transaction to the blockchain and the payment gateway screen for the new blocks that contain this transaction (you could add a unique id in the note field and locate that)? would this cause security risks?
  2. does this assume that the client wallet is integrated with the payment gateway? if the client is using a third party wallet, how would you expect the wallet to pass the signed transaction back to the gateway?

Thanks

1 Like

You’ve probably missed the point using that Payment Gateway phrase. The way it is explained in the article, that Transaction Gateway is the whole new beast:

As I see it and the way it can be explained, a POS provider delivers a QR code to a client that uses their wallet to sign the transaction, and that QR code is created with the help of retrieveUnsignedTransactionsForAccount:

TransactionGatewayInterface {
   submitUnsignedTransaction(Transaction):void
   retrieveUnsignedTransactionsForAccount(accountAddress):List<Transaction>
   submitSignedTransaction(Transaction):void
} 

When a client signs the transaction, a smart contract calls submitSignedTransaction, and then all the magic they talk about can take place (paying taxes, submitting off-chain document, …).

So, not a security risk, rather a simplification.

The Signing Wallet is a client application used by consumers to manage and protect their Algorand account and to sign transactions received from the Transaction Gateway. The Signing Wallet can be a mobile app, web app, or desktop application. When the Signing Wallet receives a transaction, it notifies the user and displays the details to the user, including the receipt stored off-chain, and then prompts the user to either accept or reject the transaction. If the user agrees, then the wallet will sign the transaction and return the signed transaction to the Transaction Gateway.

Hi Ivica,

Thanks for the followup. I read through the tutorial again and I believe I was understanding it correctly. Maybe you can confirm my understanding below? So the Transaction Gateway is essentially an aggregation of API endpoints and a standalone app and backend, akin to a service like BitPay.

My question is specifically concerning this diagram, where the signing wallet is required to return the signed transaction back to the Transaction Gateway. I believe this is the standard for a lot of crypto payment services. Is the sole reason to require that the signed transaction be submitted by Transaction Gateway (rather than the wallet and however any third party wallet chooses to broadcast the transaction) so that the Transaction Gateway can easily collect additional data for its other services?

I’m imagining if you let the consumer signing wallet broadcast it however it chooses, then just screen the newest blocks on the blockchain for whether that transaction has appeared, would that not accomplish the same goal? (If you have trouble linking the transaction, you could easily add something in the note field and match on that)

Is the sole reason to require that the signed transaction be submitted by Transaction Gateway (rather than the wallet and however any third party wallet chooses to broadcast the transaction) so that the Transaction Gateway can easily collect additional data for its other services?

I believe so. The Transaction Gateway provider has absolute control over the payment and the risk of involving the third side is avoided.