Ambiguous Split Payments Definitions

[marcoonroad]

Just a thought. On the PoS / Gateway world, Split payments mean multiple sources of the payments, that is, the customer, can use many means to perform a single payment. For instance, the customer can pay a purchase with a Credit Card, a Discount / Gift Voucher and another Credit Card from a different issuing bank or acquirer bank.

The real complexity of PoS Split Payments lies behind handling multiple transactions as a single one. How can we ensure that between the time of authorizing payments and the store side of settling them, there's no invalid, out-of-scope state change? That is, suppose that the first mean of payment is a Debit Card. How can we ensure that the funds are still there after the last mean of payment is approved??

You may wonder, just approve-and-settle at the same time. But it has another complexity, if the last mean of payment fails (for instance, insufficient funds), the store must deal with the burden of refunds for the previous means. And fees for refunds could be really expensive!

The general implemented solution is to put a short-time hold on the mean of payment. After all the means of payments pass, the store just settle all the payment's holds. In any case of failure of a mean of payment, the store just releases all the holds associated with the payment. Keep in mind that hold is a feature implemented on banking services level.

On the other side, there's another Split Payment definition. It is associated with the Online Marketplaces, where a customer can make a purchase of diverse products, each one from many sellers and suppliers. This kind of Split is not complex, it just look on the invoice to gather all the product data, and relay the transaction for the associated sellers and suppliers. A small fee from the purchase is claimed by the Marketplace service provider.

Given that both definitions are different, but not exclusive, why not just merge them? I mean, let's call Split Payment a blockchain transaction made of multiple sender accounts and multiple receiver accounts. A Smart Contract for a Split Payment, so, would deal with such merged definition. In this Smart Contract, a Marketplace account (which claims fees after the checkout) inputs product data and track sellers, while, on the same time, accepts multiple sources of payment from a given client.

To avoid subtle attacks here, the customer pays from different accounts, but must open an associated commitment, previously & off-chain agreed upon hashes secrets. Likewise, to protect the purchase information, the product data could be hidden as well under hashes. The Marketplace account itself could on an off-chain basis track all the associated sellers and their allocated payment parts.

(Might still need further discussion...)