- From: 段超(泰麒) <zephyr.dc@alibaba-inc.com>
- Date: Mon, 01 Jun 2015 16:32:43 +0800
- To: "'Manu Sporny'" <msporny@digitalbazaar.com>, "孙倩(雪迪)" <sunqian.sq@alibaba-inc.com>, "'Web Payments IG'" <public-webpayments-ig@w3.org>
- Message-ID: <056701d09c45$87cadd80$97609880$@alibaba-inc.com>
Hi Manu,
Please the check the following replies for your questions. And since these
web payment capabilities may be particular in China, we will prepare some
new use cases for the capabilities, we have the obligation to provide the
according use cases for them.
I understand QRCode payments as a general feature, but don't understand
these requirements, could you elaborate, please?
Reply:
There are 2 modes are frequently used for QRCode payments:
1)The QRCode contains invoice's information for the products, payer can use
his/her app in cellphone to capture the QRCode, and then app will get the
invoice via QRCode captured and pay for it.
2)QRCode appears on payer's app, payer shows the QRCode to cashier,
cashier's app will capture QRCode and get payer's account information which
can be used to finish the payment process.
> l Data encoding and encryption for invoices
Why do you need an encrypted invoice via QRCode?
Reply:
In the first mode talked above, the payee's information is contained in the
QRCode as an invoice , such as payee's account. If the invoice is plaintext,
the invoice could be captured and modified by man-in-the-middle attack. And
as plaintext, payee's information could be stolen to make fake trades and
etc. So, the invoice contained in the QRCode has to be encrypted.
> l Generate qrcode with client characteristic data
What does "client characteristic data" mean?
Reply:
Client's characteristic data means some specific data of payer's smart phone
or other terminals (such as pad and wearable devices) on the client side.
Use these data, we can make QRCode unique at one time for one payer to avoid
fake transaction.
------------------------
I don't understand what "payment under guarantee" means. Could you please
elaborate with a use case?
Reply:
“Payment under guarantee” is usually appeared in Client To Client mode.
Example：Jack has established an online store on a payment agent's website
to sell pants. Donna want to buy a pair of pants in Jack's online store. But
Donna doesn't trust Jack because she doesn't know him at all. She doesn't
know if she could receive the pants after she paid for it. However Jack's
online store is founded on the payment agent's website which provides
payment under guarantee mode. Donna could pay to the payment agent. Jack
will be told that funds have been received by payment agent, and send the
pants to Donna via Express. When Donna get the pants, she will tell payment
agent, and payment agent will move funds of the pants to Jack's account.
During the payment process, Jack and Donna both got payment agent's
guarantee.
> l Storage of payment’s status(include placed an order, paid to
> Payment Agent, received products or services, paid to merchant)
Where is the payment's status stored?
Reply:
Payment's status is stored at payment agent's side, because the guarantee is
provided by payment agent during the payment process.
> Protocol for transmitting between payer and payment agent, payment
> agent and merchant
What is transmitted, the status of the payment? Or something else?
Reply:
Everything transmitted during the transaction needs protocol to regulate the
form. Such as Merchant's ID, serial data, order number, payer's information
and payment's status, etc.
> l Handling dispute in the process
What are the kinds of disputes that need to be handled?
Reply:
Because of the characteristic of "payment under guarantee" mode, payment
agent has to be a neutral role between the payers and payees. When a payer
paid for a product but didn't get it for a long time , or a payee sent
product to a payer for several days but didn't get confirmation by the
payer, there would be some disputes between payers and payees. Payment agent
has to handle these disputes.
> l Storage of payer’s private information
Where are the payer's private information stored?
Reply:
Some sensitive information of payer's should not be stored during the
transaction, such as every kind of password, card's expired date, etc. But
some payer's private information could be stored in payment agent's
databases, such as payer's name, address, age, gender, phone number, etc.
Payment agent may need these information to make some analysis.
------------------------
> risk monitoring
Which actors / roles do the risk monitoring?
The payers, payees, or account providers?
Reply:
Payment agent has to do the risk monitoring. Because payment agent will
transfer funds between payer and payee.
> l Risk monitoring rules according to different transaction types
Can you provide a number of examples of the types of rules that can be used
based on the transaction types?
Reply:
Such as limit of every day's payment money, if the limit is $5000, a payer
could not pay more than $5000. Or limit of every day's withdrawal, if the
limit if $200, a payer could only withdraw $200 from his/her virtual account
to bank account at most. The last example, there would be a maximum limit of
virtual account's balance, if the limit is $6000, the balance is
$5000 now, then the payer could recharge less than $1000 into the virtual
account.
> l Recognizing risky transactions by monitoring rules
Elaborate more, please.
Reply:
Payment agent has to be capable to recognize risky transactions.
First of all, payment agent may set up several monitoring rules, such as
limit of every day's payment money, limit of every day's withdrawal, limit
of virtual account's balance, etc. Then payment agent could deploy an
automatic monitoring system which contains monitoring rules to recognize
risky transactions.
> l Alert about risk through email, sms, etc
Where are the alert preferences kept? Are they in a standard format along
with the rules? Does this need to be standardized?
Reply:
The risk monitoring system is kept by the payment agent, so the alert
preferences should be kept by payment agent too. Different payment agent may
have its unique risk monitoring system, and they will have their own format
along with the rules. But because the alert is sent through open channel and
the alert message could be stolen easily during transferring, so there
should not be any sensitive information which included in alert message,
such as payer's password, any information of bank card, etc. Therefore the
contents of alert need to be standardized.
---------------------
> provisions transferring
I don't understand what "provisions transferring" means.
Reply:
When a payment agent transfers funds between payer and payee, the funds will
move from payer's bank account to payment agent's bank account.
Then after the payer has confirmed to receive products or services, or at
settlement time, payment agent will move the funds from its bank account to
payee's bank account. In this process, payment agent has to reserve some of
payer's funds as provision to avoid all of payer's funds are moved for other
things, such as investment. Payment agents may need the funds paid by payer
to do invest or something else to make profits. This cannot be forbidden,
but need to be standardized. What percentage of funds should be reserved as
provisions should be regulated.
> l The bank transaction fund settlement to payment agent’s account
I don't understand this, could you elaborate? Is this the movement of funds
from the payer to the payee? Or is this the movement of funds from the payer
to an escrow account?
Reply:
As the reply above, payer's funds are firstly moved from his/her bank
account to payment agent's bank account.
> l payment agent’s account fund settlement to merchants’ bank
> account
Is this the movement of funds from an escrow account to a payee?
Reply:
Same to the reply above, after payer has confirmed to receive products or
services, or at settlement time, payment agent will move the funds from its
bank account to payee's bank account.
If you could provide a few new use cases, I think that would help me
understand the sorts of capabilities you'd like to see as well as where they
fit into the payment phases.
Reply：
Ok. Since these web payment capabilities may be particular in China, we
will prepare some new use cases for the capabilities, we have the obligation
to provide the according use cases.
段超 (泰麒)
Zephyr Tuan
集团安全部_标准化与安全新技术
Corporation security_standardization and new security research
-----邮件原件-----
发件人: Manu Sporny [mailto:msporny@digitalbazaar.com]
发送时间: 2015年5月29日 10:23
收件人: 孙倩(雪迪); Web Payments IG; 段超(泰麒)
主题: Re: Add new capabilities to Payment Architecture Priorities
On 05/28/2015 10:20 AM, 孙倩(雪迪) wrote:
> We have added 4 new capabilities for the “Payment Architecture
> Priorities”, which are qrcode payments, payment under guarantee , risk
> monitoring and provisions transferring, please review them.
Hi 孙倩 and 段超,
I have reviewed the new capabilities and have a few questions:
------------------------
I understand QRCode payments as a general feature, but don't understand
these requirements, could you elaborate, please?
> l Data encoding and encryption for invoices
Why do you need an encrypted invoice via QRCode?
> l Generate qrcode with client characteristic data
What does "client characteristic data" mean?
------------------------
I don't understand what "payment under guarantee" means. Could you please
elaborate with a use case?
> l Storage of payment’s status(include placed an order, paid to
> Payment Agent, received products or services, paid to merchant)
Where is the payment's status stored?
> Protocol for transmitting between payer and payment agent, payment
> agent and merchant
What is transmitted, the status of the payment? Or something else?
> l Handling dispute in the process
What are the kinds of disputes that need to be handled?
> l Storage of payer’s private information
Where are the payer's private information stored?
------------------------
> risk monitoring
Which actors / roles do the risk monitoring?
The payers, payees, or account providers?
> l Risk monitoring rules according to different transaction types
Can you provide a number of examples of the types of rules that can be used
based on the transaction types?
> l Recognizing risky transactions by monitoring rules
Elaborate more, please.
> l Alert about risk through email, sms, etc
Where are the alert preferences kept? Are they in a standard format along
with the rules? Does this need to be standardized?
---------------------
> provisions transferring
I don't understand what "provisions transferring" means.
> l The bank transaction fund settlement to payment agent’s account
I don't understand this, could you elaborate? Is this the movement of funds
from the payer to the payee? Or is this the movement of funds from the payer
to an escrow account?
> l payment agent’s account fund settlement to merchants’ bank
> account
Is this the movement of funds from an escrow account to a payee?
If you could provide a few new use cases, I think that would help me
understand the sorts of capabilities you'd like to see as well as where they
fit into the payment phases.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Web Payments: The Architect, the Sage, and the Moral Voice
<https://manu.sporny.org/2015/payments-collaboration/>
https://manu.sporny.org/2015/payments-collaboration/
Received on Monday, 1 June 2015 08:33:32 UTC