The mission of the Web Payments Working Group is to make payments easier and more secure on the Web.
Questions? Contact Ian Jacobs <ij@w3.org>.
老王视频加速器
Posted onJune 18, 2023byIan Jacobs
In late May, about 25 people participated in the first code-a-thon (中国上instagram加速软件) of the Web Payments Working Group. We organized three, 2-hour videoconferences, separated by 22-hour blocks of time for independent collaboration and coding. We learned a lot and saw some great demos!
中国iphone怎么上ins
On the first day participants introduced seven topics. Four of those ended up gaining traction, and we reviewed their progress on the second and third days. I summarize them here.
Payment App with Web Authentication / FIDO Provisioning
Before the code-a-thon, our colleagues from Entersekt had developed a proof of concept for Web-based payment app that supports Web Authentication. In this demo, the user has a payment app from their bank, and the bank authenticates the user as part of risk assessment. Entersekt showed us a video with the following two flows:
Enrollment: While interacting with their bank, the user installs a Web-based payment app. The payment app prompts the user to enroll a FIDO authenticator. In the video the user enrolls via the phone’s fingerprint reader.
Transaction: During a subsequent transaction, the user chooses to pay from the same payment app. The user selects the card to pay with, re-authenticates with a fingerprint scan, enters a PIN, and (after some risk assessment process) the bank returns a proof of payment to the merchant who submits it to complete the transaction.
Within the Web Payments Working Group we have been discussing a vision where payment apps are “first-class objects” in the browser, easily registered and managed via browser settings. We face an important question: “Will users want to register payment apps explicitly or will that create too much friction?” It has been argued that users are familiar with the ceremony of downloading and installing apps from an app store. If we adopt a similar approach for payment app registration, this might help increase the user’s understanding of which powers to grant to the payment app.
With that discussion as a back drop, Entersekt worked with the Chrome team to mock up a registration ceremony for their payment app. On the final day of the event they presented a video of a payment app registration mockup. This video only shows the payment app registration and provisioning; the checkout portion of the user experience would be the same as the first video.
This demo is likely to help us advance the conversation about payment app lifecycle and the relationship of explicit registration to trust, privacy, and security.
QR Codes for Multi-Device Checkout
For several years, people have pondered how QR codes might be used as part of Payment Request flows. We saw our first proof of concept during the code-a-thon. Entersekt brought a second demo to the meeting with the following flow:
The user is shopping in a desktop browser and, at checkout, opts to pay via their phone, leveraging a QR code for communication.
On the fly, the browser installs a Web-based payment app from the user’s bank
That payment app computes and displays a QR code that represents some information about the transaction, including the amount and merchant identity.
The user opens a payment app from the same bank that runs on their phone. That payment app scans the QR code and prompts the user to confirm the transaction.
The bank server updates the payment app on the desktop to indicate that the transaction has been successful, and the merchant receives a proof of payment.
On the last day, Entersekt shared a QR payment video to illustrate the flow, including new consent mockups that they developed with Chrome.
Authenticate to Pay (Minimal UI)
Last year, the Chrome Team and Coil to explore an “authenticate-to-pay” feature in payment apps that reduces the total number of user gestures to complete a transaction while simultaneously incorporating multi-factor authentication. Worldline colleagues expressed an interest in enhancing one of their existing Payment Request demos with this authentication UX. Working closely with the Chrome team, they made progress on their demo over the two days. The Worldline demo was shared a few days after the code-a-thon. Worldline indicated that they would like next to enhance the demo to satisfy PSD2 requirements, e.g., with an issing bank as the relying party.
The animation below also show the “authenticate-to-pay” user experience. At this time it is only experimental, it only runs on Android, and it does not yet leverage Web Authentication. But I think there is sufficient interest that the Web Payments Working Group will continue to develop the idea.
Here’s what’s going on in the animation: in general payment apps can open windows for user interaction. However, in the authenticate-to-pay user experience, the payment app tells the browser: “if you launch me, I won’t open a window. Instead, please display the amount, beneficiary, and source of funds to the user and prompt them to authenticate using these credentials.” The browser, not the payment app, opens a small window for authentication. The browser then launches the payment app with the results of the authentication. The payment app does not open a window, but does evaluate the authentication results fed to it by the browser as part of completing the transaction. Because the browser opens a small window, this user experience has been nicknamed “minimal UI.”
Mobile Money on the Web
In the past we have had discussions with the GSMA about connecting operator-run mobile money systems to Web payments. The code-a-thon offered us a chance to catch up with GSMA colleagues. Opportunities to bring mobile money to the Web may be growing as smart phones are becoming more common in regions where mobile money is a widely-used payment method.
Although no code emerged from the discussion, Adrian Hope-Bailie did start work on a document for ongoing discussion: Mobile Money and Web Payments. It is possible that we may see more experimentation around mobile money and Web payments through the Mojaloop Project.
Undeveloped Ideas
Although people also expressed interest on day one in the last three topics, they did not lead to further discussion:
I pitched the idea of demonstrating a comprehensive authentication “cascade” that would provide the “best experience” if supported in the user’s environment, or fall back to a variety of alternatives.
We also discussed two points raised by Airbnb during TPAC 2023: integration of “card-on-file” payments into the Payment Request ecosystem, and leveraging responses to Payment Request for account creation.
安卓手机中国怎么上instagram
I think that the success of the event hinged largely on preparation by the participants. Entersekt, Worldline, Coil, and Google had all prepared code or documentation. As always, demos focused our attention, raised compelling questions, and drove discussion. I want to thank all the people who brought code to the event.
The Chrome team helped people prepare by creating a 中国上instagram加速软件 for people who want to experiment with the Payment Request and Payment Handler APIs. I encourage you to try it out, share your project, and provide feedback on the starter kit.
Some additional notes:
Time zones created the usual issues for global participation.
We relied on IRC channels for chatting over multiple days. We did not do enough to ensure that people would have access to discussion even when they disconnected from IRC. We will definitely need to fix that for a future event (by using a proxy, or Slack, or some other solution).
Thanks to all the participants! I look forward to seeing more proofs of concept soon.
老王视频加速器
Posted onMay 18, 2023byIan Jacobs
Following TPAC 2023 discussions last October I summarized how the Web Payments Working Group’s 苹果怎么翻ins墙 had been evolving based on experimentation, implementation feedback, and discussion.
Now it is time to share a new vision for payment apps, one driven by a host of changes on the Web, including our experience with Web payments APIs. These changes give us an opportunity to provide superior checkout experiences through payment apps compared to other Web technology.
Before we get started, here’s a quick reminder of some terms:
In the Payment Request architecture, the user interacts with a payment app to respond to the merchant’s request for data.
Payment apps today come in three flavors: built into the browser, native mobile, and Web-based. We call the latter two “third-party payment apps.”
The Working Group is defining the Payment Handler API as a standard way for Web-based payment apps to register and interact with browsers. Thus, a payment handler is (1) a Web-based payment app that (2) responds to Payment Request API.
A preliminary version of the Payment Handler API (a draft) ships today in Chromium browsers.
For a summary of some current benefits of payment handlers, see my October 2023 post on the 国内用户真的用不了GooglePlay商店了吗？ - 知乎:2021-11-16 · Gplayspace相当于生成一个空间，空间内的软件有富强功能，能用它来玩外服的安卓游戏，也能用来看哔哩哔哩的海外版权视频，更能将本地的软件添加进去然后进行加速。 内置的排行榜是和谐过的，一些应用是不显示在上面的，可自行搜索下载。在此需要注意的是，里面屏蔽了所有不符合中国法 ….
Recent Chrome Enhancements to Support Payment Apps
The Chrome team has been very active over the past six months improving payment apps. (Thank you Chrome Team!) The October post included two points related to payment apps:
The “sheet” is the browser supplied UX for accessing browser-stored addresses and contact information, and for selecting a payment app when more than one is available. The Shopify experiment with payment Request suggested that the sheet surprised some users. This was also borne out by Mozilla’s internal research on their own implementation of “Basic-Card.”
Experimentation has led browser vendors to conclude that the people closest to the details of a given payment flow should build that experience. For this reason, browser vendors are now focused on providing the “pipes” to enable excellent third-party app experiences. Indeed, realizing this in 2018, Mozilla abandoned their work on the Basic Card implementation. Similarly, in January 2023, the Chrome team followed suit and 手机vnp的服务器怎么填 plans to gradually remove their build-in support for Basic Card.
Regarding the sheet, we have also heard from potential payment app providers that they would like to manage and return user contact and shipping address information and would like to manage it instead of the browser. The Chrome team therefore proposed a means to delegate requests for shipping address and contact information to payment apps.
Just-in-time registration, which facilitates payment app distribution.
Skip-the-sheet, which improves the user experience by automatically launching a payment app under appropriate conditions such as when only one is suitable for a transaction. We have also been discussing user configuration of a “preferred payment app,” which would enable automation in more scenarios.
Thanks to these changes, we are exploring a few streamlined user experiences that do not involve the sheet. They start when the user clicks a payment button, after which:
If the user has more than one matching payment app, the browser displays an app selector instead of the sheet. Co-Chair Adrian Hope-Bailie created a presentation on the app selector approach last October. A key point of this presentation is that there is precedent for this type of user experience (see also the Web Share API). Thus, there is some expectation that app selection will be less surprising than a “sheet” experience.
Sample Web Share user experience
In both flows, the payment app can open a Window for user interaction, then return data to the merchant. We have started discussions of a third flow:
If the user has only one matching payment app, and the payment app has registered with the browser its ability to do “authentication only”, then the browser automatically performs biometric or OS-level authentication. The user authenticates, and the browser passes the results (the “authentication assertion data”) to the payment app. In this scenario, the payment app does not open its own Window. The entire user experience —display of total amount and other transaction information, and the prompt for authentication— is managed by the browser.
This last flow in particular is likely to make payment apps the best user experience on the Web: you push the buy button and then authenticate and you’re done. By leveraging payment apps and authentication together, we thus have the opportunity to simultaneously improve usability, privacy, and security.
One last comment about the sheet before we move on: if you have use cases that benefit from the sheet, please let us know!
Minimal UI Flow
Browser Changes that Affect Payments
In parallel with our work on Web payments, browsers are changing in other ways that have an impact on payments. As a result, we are investigating which additional capabilities payment handlers might need to enable streamlined checkout in light of these changes.
Restrictions to Cross-Origin Sharing and Storage
To enhance user privacy on the Web, browser vendors are moving quickly, and with some unity, to restrict cross-origin data sharing and to clamp down on any form of browser fingerprinting. These initiatives include standardization activities (e.g., automatically blocking third-party trackers, requiring remote origins/iframes to explicitly request first-party storage access, etc.) to help harmonize these new browser behaviors.
In the payments ecosystem, merchants often rely on payment service providers who include code via iframes in merchant pages. Because of these browser changes, this third-party content will lose cross-origin access to information stored in the browser (e.g., via cookies or indexDB). My understanding is that a big motivation is to reduce tracking (especially as is done today to enable targeted advertising). However, these browser changes will also have an impact on other scenarios such as risk assessment during a payment. Browser changes may potentially break existing code such as EMV® 3-D Secure implementations. For this reason, the Chrome team recently discussed changes to SameSite behaviors with the Web Payments Working Group and presented some mitigation strategies.
I do not think we have a clear vision of the path forward. A variety of groups are discussing use cases to inform designs.
Privacy as a Priority
Beyond changes to storage, browsers are taking further steps to improve user privacy, so we have been tracking conversations on trust tokens, efforts to reduce fingerprinting, and others.
The Chrome Team also developed a privacy threat analysis of Web payments APIs. This led to a series of 在中国怎么上snapchat to payment apps to reduce the risks of cross-site tracking, fingerprinting, and unnecessary data sharing.
The mitigation strategies we have discussed —raising user awareness about the role of the payment app, ensuring that default behaviors protect user privacy, and others— also contribute to our emerging vision. For example, the Chrome team is researching privacy improvements such as UI treatment to raise user awareness when sharing data from a payment handler with an ecommerce site.
Web Authentication is Now Widely Deployed
Meanwhile, Web Authentication —half of FIDO2 along with the CTAP spec— is now shipping in all major browsers with more and more authenticator support, all very exciting. Because strong customer authentication (SCA) plays such an important role in payments (e.g., under PSD2 regulation in Europe and in 3-D Secure flows), we are having a lot of discussions about how to combine Web Payments APIs with Web Authentication to optimize the user experience of some payment flows.
If you’d like to help raise awareness about Web Authentication, please consider joining the WebAuthN Adoption Community Group.
Continue to Part II of this post for “A Way Forward.”
Installing a mobile app is now a familiar experience. The Progress Web App (PWA) approach attempts to make Web applications more app-like (for both mobile and desktop). By moving payment apps more in this direction, we think we can solidify user acceptance of payment app lifecycle management, and solve some of the UX challenges raised by changing browser behaviors.
The user relationship with an app begins with a registration ceremony through the browser’s UI. Although there are some concerns about adding friction to the user experience of payment app registration, we think explicit registration ceremonies can simultaneously mitigate several of the risks described in the privacy threat analysis and provide a better user experience overall.
Before describing a few ideas for registration ceremonies, here are some of the activities it could include:
Requiring a user gesture before a payment app can be invoked automatically (skip-the-sheet).
Granting first-party storage access. This level of access could enable a payment app to recognize the user (through Web Authentication or other means) and maintain a session as the user makes use of the payment app across origins.
It is our expectation that the user experience of interacting explicitly with a payment app will be superior to alternative checkout implementations such as iframes that require the same types of consent. In addition, we think it will create better outcomes because a user is more likely to be comfortable granting privileges to a known app than to an unfamiliar piece of code embedded in a web site.
We are likely to see a variety of payment app registration ceremonies, both during a transaction and outside of a transaction. Here are some ideas; the first two are already deployed:
On a site that distributes payment apps (e.g., our fictitious bobpay.com), the user clicks the “Get Bobpay!” button, which prompts the user confirm registration.
During a transaction, the browser offers a payment app for just-in-time registration. The user selects it, which prompts the user to confirm registration.
In the browser’s settings, the user can easily add and configure payment apps. Indeed, much in the way that browsers out of the box list a few well-known search engines but allow the user to add others, we’d like to see browsers list a few well-known payment apps out of the box. Browsers could provide very streamlined UX —like a single checkbox— for registering a payment app, granting first-party access, etc.
One key to these ceremonies or others will be the quality of the UX provided by the browser. One aspect of that quality may well be how well payment apps integrate into the overall app model of a given platform.
Combine Web Authentication and Web payments
The Web Payments Working Group and Web Authentication Working Group jointly discuss payments use cases. We have reviewed several proposals that we think will improve transaction flows:
A Web Authentication Level 2 feature allowing cross-origin iframes (e.g., code from a user’s bank embedded in a payment handler distributed by another party) to retrieve (but not create) Web Authentication credentials. This should allow code embedded in a payment handler (such as issuing bank code) to authenticate the user during a transaction without requiring a full-page redirect to another site. We think that staying near the merchant checkout context is a superior user experience than a full-page redirect to another site.
An enhancement to Web Authentication that enables a relying party to create Web Authentication credentials usable by itself and another origin. This feature would enable, for example, a payment handler to control the authentication experience for the user, using credentials minted by the user’s bank. The payment handler could verify the authentication for its own purposes, then pass the same credentials to the issuing bank for its own purposes. In other words: less user interaction with all the trust (by two different parties involved in the transaction).
A proposal to leverage the combination of Payment Handler API and Web Authentication to fulfill transaction confirmation use cases (e.g., part of PSD2 regulation).
A proposal to use the same user gesture for two purposes: initiate Web Authentication and launch a payment handler.
For all of these, we seek to take advantage of Web Authentication in payments flows. The last two push the relationship further and thus would require some API changes grant special powers to payment handlers.
Make it very easy for users to log in. One way to increase session persistence would be to make it harder to clear cookies, but that strategy is not likely to gain traction with browser vendors. Therefore I am trying to emphasize making it “easier to get in” instead of “harder to get out.”
Improve security by not relying on cookies, which are exfiltratable.
Make it easy for users to consent to sharing information across origins for payments.
Minimize the need for user interaction.
Some of these things can be done today, such as one-click login using passwords stored in the browser, and Web Authentication for password-less login. Neither of those relies on cookies (point #2). Stored passwords are distinguished from cookies in the browser UX to clear stored data, and can thus be made more persistent than cookies.
New APIs are emerging that may also help, including the Credential Management API (to automate logins under some conditions).
We need to do more collaborative work with the payments industry to document requirements, and then to map those to both current and new technologies.
Code-a-thon!
We think that adoption of these proposed features would add great value to payment apps for a variety of payment flows. To prove it to ourselves, the Web Payments Working Group is running a virtual code-a-thon later this month. I look forward to seeing cool innovations and demos, and to sharing them in this forum in early June.
Before I go, I’d like to again thank all the engineers who are contributing to improving payments on the Web! And many thanks to Marcos Caceres and Danyao Wang for feedback on this post.
老王视频加速器
Posted onMay 6, 2023by苹果怎么翻ins墙
Please see Payments and Authentication: Driving toward a Whole Greater than Parts. Because I wrote about the work of multiple groups, I chose the general W3C blog over this one.
老王视频加速器
Posted onApril 14, 2023by手机vnp的服务器怎么填
As people shelter in place due to COVID-19, Web usage has increased dramatically. ISPs, platform providers, telcos, content providers, and most other stakeholders are working to ensure that the network can accommodate the surge. It will be very interesting to see which of these behavioral changes remain commonplace once the crisis subsides.
Two weeks ago, against this preoccupying backdrop —as well as some more playful and colorful green-screen effects on WebEx— the Web Payments Working Group held a big meeting to check in on our activities to improve the Web platform for payments and e-commerce (agenda, 在中国怎么上snapchat).
We reworked our Dublin face-to-face agenda into four 2-hour video conference calls on five topics: payment apps, Secure Remote Commerce (SRC) and Payment Request, authentication, open banking, and merchant feedback.
Improving Payment Apps
In recent months, most of the group’s technical focus has been on improving payment apps, the software (Web-based payment handlers or native apps) that people use to respond to payment requests. In particular, the Chrome team conducted a detailed 在中国怎么上snapchat, which led to a set of proposed changes to payment handlers. That second link includes summaries of all the proposals, so I won’t repeat them here. Together the proposals aim to reduce cross-site tracking, fingerprinting, secondary use of collected data, and unnecessary information sharing.
Today only Chromium browsers support skip-the-sheet. Because merchants in particular have a strong desire to understand the user’s transaction journey, there was strong support for defining and promoting consistent skip-the-sheet behavior across browsers.
Today Chrome skips-the-sheet to an already installed payment handler even when an installable payment handler could also be used. That is: Chrome favors installed payment handlers over just-in-time installable payment handlers. The Working Group did not support this approach and a helpful guiding principle emerged from the discussion: by default, a browser should favor user choice of payment handlers over automatic behavior to reduce user gestures (such as skip-the-sheet).
This principle is likely to play a role in answering another design question: should a browser skip-the-sheet to a payment handler that supports delegation of all merchant requested data, even if another one that does not support full delegation could otherwise be used?
Similarly, this principle suggests support for a proposal to find and show just-in-time installable payment handlers, even when the user already has one or more applicable payment handlers for a given payment method.
We also discussed a number of user interaction and user configuration topics:
Good support for 中国iphone怎么上ins (or perhaps in some cases notification) before enabling powerful payment handler features.
Requiring some form of gesture to grant a payment handler 手机vnp的服务器怎么填.
Requiring some form of user gesture before just-in-time installation and skip–the-sheet can be used in combination.
User configuration of a “preferred payment handler” to enable more streamlined checkout flows.
A proposal that a single user gesture be usable simultaneously to trigger Web Authentication and launch a payment handler.
As a next step, we will consider the feedback on the proposed changes and present a synthesized approach to installation and display that improves user awareness and privacy, maximizes user choice, and facilitates strong authentication, all while continuing to streamline transaction flows.
The Working Group also appreciated learning about a recent security analysis of Web Payments carried out as a Master’s Thesis. We expressed our appreciation to @crowgames, who has summarized three key findings and already begun collaborating with browser vendors on fixes.
免费翻国外墙的app
Our primary objective on the second day of the meeting was to drive toward consensus on an architecture for doing EMV® Secure Remote Commerce (SRC) through Payment Request API. We reviewed in detail a series of flow diagrams for first time users, returning recognized users, and returning unrecognized users.
There will be one Payment Method Identifier (PMI) per SRC system. All the PMIs will share a common origin (domain name).
There will be a “common payment handler” hosted by the same domain. All of the Payment Method Manifests of the SRC systems will refer to the common payment handler as the default payment handler. Having a common payment handler makes it easier to avoid “wallet selection” in the user experience. Instead, when the merchant accepts an SRC Payment method, the browser will be able to skip-the-sheet into the common payment handler.
Once launched, the common payment handler will only have two roles: (1) to route users to an SRC-I identified by the merchant (2) to store information that will make it easier to recognize a returning user in a future transaction. This approach has the appeal of leveraging existing merchant relationships with SRC-I’s as well as deployed code.
Participants raised some interesting points:
The data model of a future SRC payment method definition will, for the most part depend on the EMVCo specification. However, it will also need to support custom data passed by the merchant to the target SRC-I.
We need to make clearer whether the common payment handler will the preferred payment handler of the ecosystem or the only SRC payment handler available.
Once we have converged on the architecture, we will be able to advance to work on a proof of concept as well as the actual specification of the payment method.
Authentication
Representatives from the Web Authentication Working Group shared updates from their February face-to-face meeting.
We discussed the decision to allow Web Authentication get() but not 中国怎么上instagram from within cross-origin iframes in Web Authentication Level 2. On many occasions we have discussed the scenario where, as part of a 3-D Secure (3DS) flow, an issuing bank may wish to insert some code in a merchant site or a payment handler. The recent decision means that at transaction time, the issuing bank will be able to call Web Authentication without the need for a full redirect to the issuing bank’s site. We hope this will enable a superior user experience at the same time it enhances security and risk assessment.
We also discussed a decision to remove the “transaction confirmation” extension in Web Authentication Level 2 due to lack of browser implementation. The feature had been seen as important fulfilling European regulatory requirements under PSD2 around “dynamic linking.” Participants expressed interest in discussing alternatives (e.g., by adding features to the browser to use FIDO authenticator keys to sign information available through the Payment Request API). I anticipate that those discussions will continue in the joint task force between WPWG and WebAuthn.
Open Banking
STET, Open Banking UK, the Berlin Group, and ISO 20022 Registration Authority / SWIFT brought us up-to-speed about various open banking activities, successes, and challenges. Here are some of the points that stood out for me:
Adoption is growing and the organizations working on APIs continue to revise them.
Strong Customer Authentication (SCA) remains a challenging topic, especially around the user experience.
In addition, the Strong Customer Authentication requirement apparently also complicates the accepted fallback solution when the open banking APIs are not available.
There remains some tension between data collection for risk assessment and privacy regulation (e.g., GDPR).
The FAPI profile of OAUTH was mentioned multiple times.
There is a growing set of activities around more use cases, including payroll and business-to-business payments.
The Berlin Group pointed out that when PSD2 is “tranposed” into national legal frameworks, this can introduce subtle differences in requirements and other challenges to interoperability.
Our colleagues from SWIFT / ISO 20022 Registration authority discussed their collaboration activities with Open Banking UK and the Berlin Group to harmonize the data model across APIs by leveraging the components of the ISO 20022 repository.
We had anticipated experiments combining open banking APIs with Payment Request and Web Authentication at our code-a-thon. A future virtual event may provide the best opportunity for experimentation.
Merchant Feedback
The Working Group values hearing about merchant experiences with the APIs.
Sumantro Das from 1-800-FLOWERS.COM, Inc. shared his experience working with Payment Request API for the past several years. In the past we have discussed findings that show how Payment request can speed up checkout. Sumantro similarly reported an uplift through Payment Request on product pages from Android. Specifically he cited a number of things he liked, including:
Flexible user interface
Built-in support for credit card input (in Chrome)
Leveraging the API in sophisticated real-time availability of product use cases.
Sumantro also gave an assessment of how Payment Request from several perspectives:
Security: Good, but needs a refresh
Timeliness: Good
Transparency: Good
Convenience: Good, but needs a refresh
Usability: Good, but needs a refresh
Universality and accessibility: needs improvement
He also made some concrete implementation suggestions:
Now a bit on the virtual meeting experience. Although I sorely missed the hallway time of face-to-face meetings, we compensated a bit by opening the bridge 15 minutes early each day for casual chit-chat. If we repeat this type of meeting, I will suggest even more open time.
Because at times 60 people participated, we skipped introductions around the table. Nick Telford-Reed suggested that next time we seek enhanced tooling support, for example being able to easily reach each participant’s affiliation and short bio from IRC or WebEx.
We surveyed the participants following the meeting and so far have heard:
Very strong consensus that two hours was a good call duration.
We may soon have another opportunity for a virtual meeting: we had great plans for our Dublin code-a-thon and there is support for holding an online version.
The co-Chairs and I agree that overall this was a successful meeting, and we might take back some lessons for our future face-to-face meetings. For example, I could imagine organizing meetings so that there is only a half-day of very focused discussion, with long breaks and open sessions for ad-hoc discussions.
facebook
The Chairs and I came away from the meeting really energized and with an emerging picture of next steps in each of these major topics, for discussion with the Working Group in the coming days:
Payment handlers: There’s a growing confidence in the direction and maturity of the payment handler architecture, with great feedback on Instagram,twitter,facebook下载注册使用教程 - 萌V小站:安装完辅助软件之后，下载好软件之后，下载软件参考上面的方法，下面是用法。 启动app ：点击手机屏幕上Instagram的app图标。 创建账户 ：点击屏幕下方的“注册”按钮，可伍选择手机号注册；手机号一定 …. Next we will turn those proposals into concrete pull requests, get review from other W3C groups, and benefit from updated implementations.
SRC: The Card Payment Security Task Force will continue to build consensus around a proposed architecture, in particular among card networks/SRC providers. However, we welcome thoughts from all the WG’s participants and urge them to join the fortnightly task force calls. Once we have sufficient consensus on the architecture the next step will be work on a proof of concept.
Open banking: It was great to hear so much progress and cooperation among STET, Berlin Group, Open Banking in the UK and SWIFT. We want to continue to collaborate with these groups on a proof of concept that leverages multiple APIs (and possibly our previous work on a credit transfer payment method). Our plan had been to do this work at the code-a-thon in Dublin that we had to cancel. We’d like to tackle this at a virtual code-a-thon, so let us know if you are interested.
免费翻国外墙的app: We expect our joint task force with WebAuthn to continue to look at dynamic linking use cases as well as the 中国版instagram app-中国版instagram app最新版安卓v1.0.0 ...:2021-6-14 · 中国版instagram app是很受欢迎的社交平台，它的交友形似非常的靠谱。平台源自于国外，但经过汉化之后，更适合国内交流。其商业元素在经过汉化之后，去掉了很多，变成了较为纯粹的交友平台，主要目的就是扩展大家的朋友圈。. This is an area which feels like we need to apply some rocket assist. The solution feels like it’s within our grasp, but we’ve not quite been able to connect the dots.
Merchant feedback: We heard more support for addressing split tender use cases (including coupons) which have been with us since the start of the group. Generally speaking, we will continue to seek increased merchant engagement in W3C discussions around Web payments.
I want to thank everyone who participated in the meeting and hope to see everyone soon in healthier times. Many thanks to the Chairs for contributions to this post. Let’s keep making Web payments better!
老王视频加速器
Posted onJanuary 23, 2023byIan Jacobs
UPDATE 2023-03-05: Due to travel restrictions around COVID-19, the Web Payments Working Group does not plan to meet face-to-face as scheduled, but will conduct a remote-first alternative meeting.
Last month, W3C renewed the 手机怎么翻ins墙 of the Web Payments Working Group through 2021. The new charter is similar to the previous one, but added explicit mention of a Recommendation-track deliverable related to the use of EMV® Secure Remote Commerce (SRC) via Payment Request API.
At the end of March we will hold our next face-to-face meeting in Dublin, hosted by Airbnb. Our 中国iphone怎么上ins is still rough, but I anticipate discussion of an SRC payment method, the status of browser support for Payment Request and Payment Handler, updates from the joint task force between WPWG and the Web Authentication Working Group, some merchant experiences with the APIs, and perhaps some discussion of the current Irish and/or EU payments landscape. Given the strong customer authentication (SCA) requirements of Europe’s Payment Services Directive (PSD2), I also expect a special focus on streamlined integration of Web Authentication into payments flows.
Regarding SRC, between now and the face-to-face meeting, we are working on a succinct description of “how SRC can work with Payment Request.” This would be the culmination of discussions within the Card Payment Security Task Force about data models and user experience requirements and assumptions. It is also an important precursor to a concrete payment method specification. My goal is for the Working Group to come together around “how it will work” during the face-to-face meeting, and then to initiate work on the payment method definition shortly thereafter.
For the first time we are meeting for a total of 4 days. Included is a 2-day “code-a-thon” where participants will demonstrate how Payment Request, Payment Handler, Web Authentication, and related APIs can be used to create compelling checkout experiences for a variety of payment method and authentication flows. I anticipate we will look at SRC flows, ACH flows, and open banking flows. We also heard from Airbnb last September interest in topics such as integrating card-on-file into the Payment Request user experience (for consistency with guest checkout), and using Payment Request as part of account creation. My hope is that the code-a-thon results in proofs of concept, fodder for good practices documentation, and ideas for new features.
I look forward to seeing colleagues in person, and also visiting Dublin for the first time!
老王视频加速器
Posted onJanuary 17, 2023byIan Jacobs
When using Payment Request API, merchants want some assurances about the nature of the user’s payment journey. The decision to use Payment Request for a given payment method might depend on answers to these questions:
Does the user have access to a payment handler at all?
Does the user have a payment handler that is immediately ready for payment?
A “yes” answer to the second question is useful when the merchant wants the greatest assurance of minimal friction for the user to complete the payment.
However, in some cases, the merchant might prefer a particular payment method and accept more friction —the user might have to sign up for an account or adding an instrument to the payment handler before completing payment. A “yes” to the first question is useful for this case.
Payment Request includes two methods corresponding to the two questions: canMakePayment and hasEnrolledInstrument. Here’s how we expect them to work.
canMakePayment
The method returns “true” when either of the following is true:
The browser knows of at least one registered payment handler for this payment method. The payment handler might be built into the browser, a Web-based payment handler registered through Payment Handler API, or a native app registered through some other platform-specific mechanism.
The browser is capable of registering a payment handler on-the-fly, for instance using information made available by the payment method owner in a payment method manifest.
Instagram在国内使用教程在国内怎么使用ins_文档下载:MAC OS X 无法上 instagram 刷新 INS 动态怎么处 理目前国内限制了登陆上 g...今天我伊说说怎么在电脑上国外网站,需要用到的是:外游加速器 下面上教程: 1.... IOS版Instagram图文视频打不开解决方法 IOS版Instagram图文视频打不开解决方法_计算机硬件及
Here is some fodder for those hasEnrolledInstrument discussions (e.g., around Secure Remote Commerce or ACH):
If the payment handler requires authentication (at some point), does the payment handler return “true” only after authentication?
Assume the merchant has some knowledge of the user’s identity (e.g., an email address). Does the payment handler return “true” only if there is an enrolled instrument associated with that identity? Presumably the merchant would provide the identifier in the payment method-specific request data, and the payment handler could consult it as part of answering hasEnrolledInstrument.
If the payment handler validates an account (e.g., for sufficient funds), does the payment handler return “true” only after successful validation?
The Payment Request API 1.0 specification only defines canMakePayment. The Editors’ draft, which is a living specification, also defines hasEnrolledInstrument. Deployed browsers (including Chrome and Safari) are starting to support it. We expect to include the method “officially” in Payment Request after we publish the final Recommendation of version 1.
The Payment Handler API defines an event to enable Web-based payment handlers to respond to the browser’s delegation of hasEnrolledInstrument(). Alas, the Payment Handler API specification is not up-to-date with our naming choices. Thus, it is currently named CanMakePaymentEvent. Of course we plan to change that to hasEnrolledInstrumentPaymentEvent; perhaps this blog post will hasten that fix.
facebook
Because canMakePayment() and hasEnrolledInstrument() methods have the potential to expose user information, browsers are expected to protect users from abuse. We discuss privacy protections in the Payment Request API spec. Our discussions about user experience (e.g., user consent for the payment handler to respond to hasEnrolledInstrument queries) are ongoing. We welcome your input on this topic.
老王视频加速器
Posted onOctober 29, 2023byIan Jacobs
In the Payment Request architecture, the user interacts with a payment handler to respond to the merchant’s request for data. As the Web Payments Working speaks with more organizations about providing services through payment handlers, it has become clear that we need to collect and socialize the benefits of this approach over other approaches.
Our colleagues from the Chrome Team gave a 中国怎么上twitter on this topic at the Working Group’s recent 中国怎么上ins of the Web Payments Working Group. This blog post borrows heavily from that presentation and a subsequent conversation with Justin Toupin (Google). It also borrows from an early proposal for a modal dialog.
What Payment Services Want
Here is a short list of Web functionality needs —from the perspective of a payment service provider— that could be handled in multiple ways:
Run the service in a top-level browsing context, often for security reasons.
Minimize distraction and other UX friction.
Let’s compare how different approaches satisfy these needs:
Payment Handlers
Redirects
Iframes
Popups
Top-level context
Yes
Yes
No
Yes
Minimize distraction
Yes
No
Yes
No
Feedback suggests that the primary and most immediate appeal of payment handlers is the potential for a superior user experience compared to iframes, popups, and redirects. Chrome displays the payment handler as a top-level origin in a modal window that does not obscure the merchant site. This is true in both mobile and desktop views. Chrome also displays the origin of the (Web-based) payment handler. The hypothesis is that this improved user experience will increase conversion rates because it does not abruptly change the user’s checkout context and because there are more security signals to foster user trust.
Many merchants today redirect users to a payment service at another origin. In the best case, this is disruptive to the user experience, but usability can degrade further when an error takes place in the payment service. For example, the user may return to the wrong location in the merchant site, or may not return at all. Payment handlers, on the other hand, preserve the original merchant context.
Payment services cannot run as top-level origins in iframes. Iframes also create a risk of click-jacking, and current countermeasures that reduce this risk would make it very difficult to implement required payment and authentication services. Compare this to payment handlers, where Chrome displays the top-level origin and thus reduces the risk of phishing.
Finally, the way that pop-ups work today makes them less than ideal for payment use cases. If the browser opens a pop-up and the user clicks on the window or changes tabs, the browser hides the pop-up behind the window. This can confuse the user. This is especially true on a mobile device because popups open as new tabs. In addition, because it can be difficult to keep track of which tab a popup belongs to, this can be particularly confusing in a scenario where the user has opened a large number of tabs while comparison shopping. Pop-ups are also generally locked down and difficult to invoke reliably due to the measures introduced by browsers to counter their abuse. Finally, some mobile browsers limit the number of tabs that can be opened at any one time (leading to potential data loss). The payment-handler-in-a-modal approach enables the browser to eliminate confusion resulting from user interactions.
Longer term benefits
We also foresee a number of additional benefits that would start to materialize once there is more interoperable support across browsers, and once there are more payment handlers. Some of these include:
make life easier
lower code development costs for payment handler developers (provided the same code works with all browsers)
browsers can enhance security by checking the digital signatures of native payment handlers (and Chrome does so in its implementation of these APIs). These sorts of checks may not be possible through other approaches.
We have also had some interesting discussions about how payment handlers might be able to increase payment method reach. For example, Klarna showed a demo where the customer received a real-time credit offer through the payment handler, and the payment handler paid the merchant by creating a virtual card. We referred to this as “riding the basic card rails” and the interesting opportunity was to allow for innovation within the payment handler without requiring any changes to the merchant Web site (provided the merchant already accepted a standardized payment method such as basic card through Payment Request). Several people have also raised the idea of connecting payment handlers to browser autofill capabilities, making payment handlers useful even on sites that do not yet use Payment Request.
During TPAC I attended a breakout session on a new idea from Chrome called portals. I wanted to see whether this might be a useful generalization of the modal dialog approach being used for payment handlers. Though very interesting, at first glance it seems it would not meet our needs. (More discussion may be appropriate, of course.)
It does seem that the modal dialog could be useful beyond payment handlers. During TPAC, colleagues from Coil, Google, Microsoft, and Mozilla began to sketch a more general modal window proposal. It would be great if we could satisfy more use cases with such a feature. More discussion is also required on this topic.
Experimenting with Payment Handlers
I have created rudimentary slide deck (Creating a proof of concept for PR API) to help those who want to experiment with payment methods and their handlers. While the data exchanged through Payment Request API by default is limited (by design), this should not limit innovation because one can define the necessary data model in the payment method.
How can you experiment with payment handlers in a world where all browsers do not yet support them? For Google Pay, Google provides merchants a sort of polyfill. Where Payment Request and Payment Handlers are supported, they are used, otherwise the JavaScript provides a fallback user experience.
Please let me know if you think there are additional benefits to the payment handler model!
老王视频加速器
中国怎么上insOctober 28, 2023byIan Jacobs
The 手机vnp的服务器怎么填 of the Web Payments Working Group expires at the end of 2023. The Working Group plans to recharter and has been discussing scope and priorities since its September face-to-face meeting.
With rechartering in mind, I share here some thoughts on the evolution of the Payment Request API (“PR API”). Although this is not (yet) an official position of the Web Payments Working Group, I believe it represents the views of a number of participants.
The Early View
We started work on PR API in October 2015. One perspective at the time was that PR API would be “an improvement on autofill.” Browsers were already storing addresses and other information for users, and our hope was that PR API would provide a better user experience for returning stored structured data, especially on mobile.
The introductory message was: “PR API is a replacement for forms.” It seems to be low-hanging fruit to replace card payment forms with PR API, so we created our first payment method: “Basic Card.” The thinking was: if all browsers supported Basic Card, it would open the door for merchants to use PR API for other payment methods.
Basic Card was never intended to be the only payment method. There are many payment methods in the world and we never expected browsers to offer built-in support for all of them. Our vision was, and remains, that “third-party” payment handlers —Web-based or native— would be available to respond to payment requests. Indeed, Google Pay, Apple Pay, Samsung Pay, and other payment handlers work today with PR API.
As part of their implementation of PR API, browser vendors created a built-in user experience we call “the sheet.” When the merchant calls PR API and requests data, the browser pops up this view that includes the total, any explanatory strings from the merchant, user contact info and shipping addressed stored in the browser, and matching payment handlers. The user selects the relevant information and hits “Ok.” The browser then sends the selected data back to the merchant.
To summarize an initial set of expectations:
All browsers would implement built-in support for Basic Card and a sheet to allow the user to quickly select stored data.
Users and merchants would like the PR API experience for Basic Card, and merchants would then adopt the API for more payment methods.
Merchants would simplify their checkout pages by having a single “buy” button rather than a potentially confusing number of payment buttons. Because the browser only shows the user matching payment handlers based on what the merchant accepts, this sheet could simplify selection.
Today three Chromium-based browsers feature built-in support for Basic Card: Chrome, Edge, and Samsung Internet Browser. I have not heard any plans for built-in support for Basic Card in Firefox or Safari.
Shopify ran an 手机vnp的服务器怎么填 with 30 or so large merchants using PR API. Although checkout times dropped 30 seconds on average (a good thing), some users were surprised by the new payment sheet and did not complete transactions.
Some payment methods include branding requirements, which could limit merchant opportunities to feature a single “buy” button.
Similarly, payment handler providers prefer direct access to their payment handler from a button, without going through the sheet. Several of them have also said that they also store contact and address information and would like the option of returning it instead of what may be stored in the browser.
The New View
Real-world implementations and experiments have taught us a lot. Here is how I see us shifting our emphasis.
Basic Card is Stable.
People may still wish to use Basic Card, but the Working Group has shifted its focus to more payment methods, notably working on a Secure Remote Commerce (SRC) payment method. We have not made many changes to the Basic Card specification lately, though we may still enhance it. Although we may not see additional support for Basic Card natively in browsers, it is possible that third party payment handlers could support it.
Explore more user experiences without the sheet. We should shift our focus from the “single buy button” view to a more conventional world where merchants continue to use payment buttons. Less functionality in the “sheet” should simplify browser implementations of PR API. We will need to continue to enhance payment handler capabilities, such as the ability for payment handlers to returned stored addresses and contact information.
Get Handlers. Browser vendors have indicated they much prefer connecting to third-party payment handlers rather than providing built-in support for payment methods. We have also heard that a strong value proposition of Payment Request API is the ability to enable payments through native (mobile) payment handlers.
An important implication of all this is that we need much stronger support for third-party payment handlers. To that end:
People from multiple companies working on the Chromium browser engine continue to add features to Web-based payment handlers in response to requests from payment handler providers. I’d like to express my exuberant gratitude to these engineers for continuing to innovate on this front!
We have identified at least one payment handler-specific capability —the modal dialog in the Chromium implementation— that is potentially interesting for other use cases. Work has begun on a modal dialog proposal that could be a more general purpose Web capability. If so, it could be appealing for browser vendors to implement, and also allow us to simplify the Payment Handler APi.
We will continue to work with browser vendors to increase support for an ecosystem of third-party payment handlers. To help support those discussions, we are more clearly documenting payment handler benefits; see this blog post on benefits.
Impact on Rechartering
How does this relate to rechartering?
I think the scope of our specification work will remain roughly the same. But we should adjust our priorities and initiatives to focus on PR API adoption:
We need more browsers to support more payment handlers.
More browser support will encourage the creation of more payment handlers.
More payment handlers will increase the value proposition of PR API to merchants.
Instagram在国内使用教程在国内怎么使用ins_文档下载:MAC OS X 无法上 instagram 刷新 INS 动态怎么处 理目前国内限制了登陆上 g...今天我伊说说怎么在电脑上国外网站,需要用到的是:外游加速器 下面上教程: 1.... IOS版Instagram图文视频打不开解决方法 IOS版Instagram图文视频打不开解决方法_计算机硬件及
中国怎么上youtub: What are the obstacles to supporting Web-based or native payment handlers? We have heard that removing the sheet and making the modal dialog general purpose could help.
手机怎么翻ins墙: Other than “more support in browsers,” what features are needed? We have heard “skip-the-sheet,” “delegate requests for stored data to us,” “connect payment handlers to autofill,” and some others.
Merchants: Other than “more payment handlers,” what is the minimum set of additional features for merchants to adopt PR API? We heard during TPAC interest in using PR API to speed up account creation, and also make it possible to create a consistent UX for cards-on-file. We need to survey merchants and get a better sense of what they would need to adopt the APIs.
With all of this in mind, the chairs and I now think that our best course of action would be to hold back on advancing Payment Request API 1.0 to Recommendation until we have more adoption. At the same time, that will give browser vendors the chance to schedule implementation of an emerging proposal to enable merchants to request pieces of an address (to reduce data exposure). This is a departure from the consensus we observed at TPAC to move ahead sooner rather than later. However, we believe that once more merchants are using the APIs, more payment handlers are available, and implementations support a new privacy feature, we will be in a stronger position to recommend the work. We plan to seek support within the Working Group for this approach over the next several weeks.
We see significant interest in these APIs and numerous parties experimenting with them. I think that securing more adoption is critical to our success under our new charter, and our planning has begun to do so.
老王视频加速器
Posted onOctober 1, 2023byIan Jacobs
The Web Payments Working Group met face-to-face 16-17 September as part of TPAC 2023 (agenda, minutes).
The meeting was well-attended, energetic, and brimming with new ideas. I left with the impression that we have a lot to do, but also that we have lots of material to work with, and a growing community to do the work.
The post is long; many thanks to Nick Telford-Reed for helping to make it shorter than it was!
Payment Request API 1.0
To publish our main specification as a Proposed Recommendation we need to address two topics:
A Webkit update following a specification change; this is underway.
The formal objection previously raised when we advanced to Candidate Recommendation for which there is a proposal for a new feature.
whether to gather implementation experience before requesting to advance Payment Request 1.0 (likely to require a number of months); or
to request to advance with this feature as optional for browsers to implement.
The consensus of the group is that the feature set of v1.0 is otherwise stable.
Payment Handlers
We believe we need more broad and interoperable support of both Web-based and native payment handlers. An important objective of the meeting was to understand how to encourage additional adoption.
The Chrome team cited a number of benefits of payment handlers, including expectations for higher completion rates, better connectivity properties, lower implementation effort, increased reliability, and improved security. Because payment handlers operate as top-level origins (unlike iframe-based checkout solutions) they provide new opportunities to streamline authentication.
Chrome demoed new features since our April meeting, including full delegation of requests for contact and shipping info to payment handlers, great tooling to aid developers, and a new “minimal” user experience where the user simply sees the total and a prompt to authenticate.
Other suggestions to expand our adoption strategy included:
Organize a hackathon to bring together, in particular, merchants, payment handler developers, and browser vendors to demonstrate the value of Payment Request and Payment Handler.
Improve tooling and testing for developers
We also looked at possible improvements in interoperability and user experience:
Chrome supports two popular behaviors that are not formally specified: “just-in-time installation” and “skip-the-sheet”. As consistency of user experience is important, we might informatively describe Chrome’s implementation and encourage other browser vendors to adopt the same behaviors.
The Chrome implementation of Payment Handler API includes a secure modal dialog where the payment handler code executes. This may be a useful type of dialog for other use cases beyond payments, which might make it more attractive from a browser maker perspective. Editor’s note: Since the meeting we have begun work on a modal window explainer.
Re-evaluating the role of the “sheet” because:
Shopify findings suggested users were surprised by this new UX element.
Browser vendors report there is a high cost to maintaining a good UX for the data contained in the sheet.
Payment handler developers have asked to be able to handle requests for stored data rather than the browser.
Mixing “applications” and “instruments” (e.g., card data) in the sheet may confuse users.
Implementers may be able to devise superior “selector” experiences, including optimizations for selection of default payment handlers.
Airbnb Experience with Payment Request
Airbnb saw Payment request API as a means to remove complex billing forms, streamline first-time bookings, connect data collection to account creation, and access more payment methods (e.g., Apple Pay and Google Pay). They shared some of their experiences (slides):
Ideally Payment Request would be “the one API.” However, Airbnb has to provide two flows to support both new and stored cards. They asked: could we integrate cards previously stored by the merchant into Payment Request?
Could Payment Request give access to label and style information in the sheet to avoid terminology differences between the sheet and a custom checkout?
Could we unify guest checkout and new account creation with the merchant, ideally as part of the Payment Request experience, so that the user creates credentials and agrees to terms of service? This suggestion raised concerns that adding too much to the API might make it too heavy-weight.
Airbnb would like to see more interoperable support for payment handlers across browsers, and access to more payment handlers, reinforcing the group’s observations about the need for more payment handler support.
Card Payments
The Card Payment Security Task Force has been working on a Secure Remote Commerce (SRC) payment method definition. Mastercard showed a new demo of three user journeys:
The demos included using Web Authentication when accessing a list of candidate cards from SRC systems, and when, on selecting a card, the issuing bank requests authentication.
The demos showed that the user might be authenticated multiple times in some flows, leading us to discuss ways to minimize friction:
A payment handler might authenticate a user directly, or embed an SRC authentication experience.
Parties might share authentication results. For example, a payment handler might authenticate the user. Some SRC systems might trust those authentication results, reducing friction when accessing the candidate card list.
A payment handler might re-use of authentication results as input to a 3DS risk assessment process, making a subsequent 3DS step-up less likely.
We briefly looked at ways to leverage identity known to the browser to simplify SRC transactions.
The Working Group strongly supported continued work by the Card Payment Security Task Force on an SRC payment method definition. Additionally, there was support for 3-D Secure through Payment Request, independent of SRC.
手机vnp的服务器怎么填
The “Basic Card” payment method is currently supported in Chrome, Edge, and Samsung Internet Browser through “built-in” payment handlers. There are currently no expectations for support in either Safari or Mozilla, which led some people to argue that we should move away from Basic Card and focus on SRC. Others said that Basic Card remains a useful payment method at least in the short term because full SRC adoption will require time, and some merchants many not move to SRC.
We organized a session on 快帆 - 简介 | Facebook:快帆. 13,313 次赞 · 31 人在谈论. 「快帆」是一款帮助海外华人用户高速访问中国网络的加速软件，可伍让境外华人从国外直连到中国国内。 both to validate that our current work is addressing industry needs, and to identify and prioritize requirements as we recharter the group.
The session organizers pre-selected 15 pain points for discussion. During the presentation, people added a few more:
Some merchants may not ship to some locations (e.g., smaller countries). One idea to help merchants was to geo-locate the IP address of the user and display a warning at the start of checkout.
Friendly fraud, such as when a child uses a parent’s account to make a purchase (without parental consent) leading to discussion about device profiles and configurations (e.g., “this biometric is authorized to make payments; this one is not.”). In practice, segmenting biometric templates raises usability issues and therefore is uncommon.
We then split into four breakout groups for “importance / difficulty” evaluation of the pre-selected pain points. Some preliminary findings:
Some pain points could be addressed through more widespread adoption of payment handlers.
Two groups suggested reframing “speed up checkout” as “find the optimal checkout speed.” For example, checkout could involve more help for new users, and could involve less friction for repeat customers.
We need to be clearer in our next conversations about audience: when we say “account-free,” what kind of account do we mean? When we say “difficult,” which stakeholder does that refer to?
The Working Group will look for patterns across the breakout group findings and otherwise continue to refine the analysis as part of rechartering.
Payments in Asia
We invited colleagues from JCB and SWIFT Asia to share updates on the payments landscape in Japan and Asia more broadly. We heard specifically about:
A new QR code standard for in-person payments in Japan. Several people expressed support for more work on QR codes for online payments in our next charter.
SWIFT initiatives around real-time payments in Australia and GPI, which focuses on improving cross-border payments.
We were treated to a demo of GPI through Payment Request API. The demo involved a push payment initiated by the payment handler, which then returned information that enables the merchant track the status of payment within the GPI system.
免费翻国外墙的app
The Working Group has discussed Web Monetization at its face-to-face meetings for over a year. We heard about progress on the Web Monetization specification since April.
On the first day of the Working Group’s meeting, Coil announced a Grant for the Web, in partnership with Mozilla and Creative Commons. According to the Web site, “Grant for the Web is a $100M fund to boost open, fair, and inclusive standards and innovation in web monetization.”
Naturally, we asked how this relates to Web Payments Working Group deliverables. Coil indicated that there is a likely need for both a payment method definition and enhancements to payment handler functionality to support the Web Monetization model. For example, today content providers include a 中国怎么上youtub element in their pages to indicate where they can receive payment. That could be replaced by calls to Payment Request API.
Web Monetization is called out in our current charter and I anticipate it will also feature in our new one.
Web Authentication and Payments
Several members of the Web Authentication Working Group joined us to talk about their upcoming new features including so-called “TLD+1” use cases, where Web Authentciation may be called from within an embedded iframe. For example, if a Web-based payment handler were to embed code from an issuing bank origin in an iframe, the issuing bank would not be able to use Web Authentication Level 1, but would be able to use the intended Web Authentication Level 2.
We also discussed:
“Carrying authentication downstream” to avoid multiple authentications (and reduce friction).
The Working Group’s current charter expires at the end of the year. In Japan the participants expressed a strong expectation that we would recharter, so the co-Chairs and I will begin work on a draft to include:
Completion of Payment Request API 1.0
Enhancements in Payment Request API 1.1
Continued work on Payment Handler API
Continued work on an SRC payment method as well as discussion of identity and user experience issues
Web Monetization in some capacity
Personally, I think more discussion is required before we include the following:
Basic Card. I think we need to reach a better shared understanding of the role of Basic Card, and then document that in the charter.
3DS support outside of an SRC context.
QR codes. The QR code discussions we had in Japan focused on physical world payments; I think we need a better understanding of the relationship to Payment Request.
As always, I would like to thank all of the Working Group participants for contributing to this effort. Each year I appreciate the camaraderie and energy boost of TPAC. I look forward to our next phase of Web payments innovation.
