동네 커피샵도
사이렌오더를 쓸 수
있을까
허형 나동진
Lunchclass

1.
Overview

Siren Order 사용해 보셨나요?

Siren Order
모바일 주문 서비스
I want coffee.

Siren Order
모바일 주문 서비스
Order & Pay

Siren Order
모바일 주문 서비스
Going for coffee

Siren Order
모바일 주문 서비스
Get coffee

Siren Order
줄을 서지 않고 모바일로 주문/결제
출근길, Drive-thru, 자리를 잡고.. Etc.
편리함, 효율성

“집 앞 작은 까페에도 동일한 서비스를 사용할 수 있을까요?”

Another Order
예상 시나리오#1
서비스가 있다는 것을 인지하고

Another Order
예상 시나리오#1
App Installation
앱스토어에서 검색 후 설치

Another Order
예상 시나리오#1
Register & Login
회원가입 및 로그인 과정을 거처

Another Order
예상 시나리오#1
Order & Pay

Another Order
예상 시나리오#1
Get coffee

Another Order
예상 시나리오#2
흠…

Another Order
예상 시나리오#2
Instance(일회성) 소비를 위해 이러한 서비스를 이용할 수 없을까요?
대형 프렌차이즈 vs 소규모

Our Order
바라는 주문 시나리오

Our Order
바라는 주문 시나리오
앱 설치가 필요 없다면

Our Order
바라는 주문 시나리오
회원가입/로그인 생략

Our Order
바라는 주문 시나리오
간편한 주문/결제

Our Order
바라는 주문 시나리오

Our Order
바라는 주문 시나리오
어떻게 하면 될까요?

Overview
다음과 같은 내용을 이야기 하고자 합니다.
• 일회성 소비를 위한 서비스를 가능하게 하는 웹 기술은 어떠한 것이 있는가?
• 그걸 적용함에 따라 어떠한 문제들이 있는가?
PWA Loginless Web Payment Push NotificationPhysical web

2.
PWA
Physical Web

• 웹에서 앱과 같은 사용자 경험을 제공
• Service worker
• Web page 로드 시 register
• Browser와 별개로 돌고 있는 worker thread.
• Browser가 꺼져 있는 상태에도 Push notification 가능
PWA(Progressive Web App)
App 설치 없이 URL 접근으로 서비스를 가능하게 하는 솔루션

PWA(Progressive Web App)
정말로 URL 전달로 웹이 앱처럼 동작하는 것이 어떠한 상황을 만들어 낼까?

• 다수의 사용자에게 자연스럽게 URL을 전달할 수 있다.
• 최소한 한번 이상 접속할 가능성이 높다.
• 피드백을 받기 용이하다.
PWA 모바일 청첩장

1. SNS로 URL 전달
2. Webview
Service worker, push enable
PWA 모바일 청첩장
3. Webpage load

PWA 모바일 청첩장
4. Push notification 5. Event 참여
결혼식 전날 입니다.
이벤트를 진행합니다.
오늘 결혼합니다 :D

• PWA인지 모르고 사용했다.
• 기존 모바일 청첩장과 다른 알림, 이벤트는 신선했다.
• 모바일 청첩장을 앱으로 전달했다면 설치 하지 않았을 것이다.
결과
Feedback (43명)
일정 시기 이후 사용되지 않은 인스턴트 서비스, PWA 사용이 장점을 가지게 된다.

URL을 어떻게 전달할 것인가?
접근성을 높이기
• Physical Web(beacon) – bluethooth 설정, 무음 Notification
• NFC – NDEF record, 사용자의 능동적 접근 필요
매장 안에 들어 섰을 때 모바일기기로 Menu에 대한 URL를 띄우고 싶다.

3.
Loginless

Loginless
또 다른 허들
• 54% - sign up 전에 떠나는 사용자 비율
• 92% - login 정보를 재설정 하기 전에 떠나는 사용자 비율
<출처: 2016 chrome dev summit sign-in on the web, Industry-Research-Value-of-Social-Login/janrain, blue>
회원가입과 로그인이 필요 없다는 것이 아닙니다.

Loginless
• 기존에 비회원 주문이 있었습니다.
• 사용자 정보를 입력하지 않고 서비스를 사용하려면?
• 주문/결제 -> 알람 -> 수령 구간동안 사용자 구분이 필요
• data는 Indexed DB에 저장
data
만에 하나 사용자 정보에 문제가 생긴다면?

• 결제 후 물품 수령 구간이라면 사용자 정보에 대한 복원이 필요
• Platform device key를 사용할 수 있을까?
• 복원 가능한 방법이 있을까?
사용자 정보가 유실될 경우
data
Loginless

Mobile device 2
Diff
Browser fingerprint를 이용한 사용자 정보 복원
Mobile device 1
• Browser level에서 device 를 구분하는 방법
• User agent (browser info, resolution)
• Canvas 2D, WebGL
• Javascript  web engine  CPU / GPU  rendering
• Rendering 결과가 devic간 조금씩 다르다.
• 추출한 data를 key로 사용
• 특정 시간, 구간에 사용자를 구분하는데 활용
Loginless
<Canvas 2D로 text rendering시>

4.
Push Notification

Push Notification
Revoke Permission

Push Notification
O2O 서비스에서 중요한 핵심 요소 중 하나
기존의 O2O 서비스들 대부분 App push를 이용

Push Notification
Serviceworker 에 의한 Push Notification 은 반드시 사용자로 부터
알람에 대한 Permision 을 구하도록 브라우저상에 구현됨

Push Notification
서비스 장애요소:
단 한번 BLOCK 당하게 될 경우 다시 알람을
허용할 방법이 거의 없음

Push Notification
사용자가 알람을 허용하게 될 확률:
5%

Push Notification
5% 를 위한 서비스를 만들 것인가?
브라우저를 뜯어 고칠 것인가?

Push Notification
다른 솔루션은 없을까?

Push Notification
WEB Page
Service
Worker
UserAgent
registrtion
Service worker registrtion
Invoke dummy subscribe()
User Allow
subscribe()
솔루션: 느린 Invoke
Permission 을 구하는 단계를 추가하여 사용자가
허용하지 않을 경우 실제 subscribe() 를
호출 하지 않도록 함
사용자가 거부하더라도 Permission 을
다시 구하는 revoke 가 가능한 상태로 유지

Push Notification
느린 Invoke 를 적용한 결과:
5% 50%

Payload Compatibility
Push Notification

Push Notification
Serviceworker 를 통한
Push-notification 은 App 처럼
Payload 에 Icon, image 등을
실어 보낼 수 있으며
메시지에 대한 응답을 구할 수 도 있다.

Push Notification
그러나
모든 브라우저 버전에서
Payload 가 정상적으로
표시되는 것은 아님.

Push Notification
브라우저 차별 하는 서비스를 만들 것인가?

Push Notification
Service
worker
Push Service
Application
Server
Push
Query()
Notify
Resp()
Notification
Service
솔루션:
Payload 대신 token을 이용해
Server 에 쿼리하여
데이터를 받아오는 방식으로 대체

5. Web Payment

인스턴스한 1회성 주문 시나리오에서 결제는?
Payment
• 결제를 위한 추가적인 앱 설치를 요구하지 않아야 한다.
• Merchant 가 사용자가 원하는 지불수단을 제공해야 한다.

Payment
결국은 확장성의 문제
Merchant 가 지불수단을 얼마나 다양하게 지원해 줄 수 있는가?

개발 플랫폼 Level 에서 제공할 수 있는 것
Payment
• 웹으로 결제가능한 지불수단 추가를 최대한 쉽게 만듦
• Merchant 에서 지불수단 추가에 따른 인테그레이션 노력을 최소화

Payment
결제 호스팅 서비스들이 쉽게 지불수단을 추가할 수 있도록 해결해 주고 있지만....

Payment
지불방식과 관계없이 같은 인터페이스로
결제요청과 확인이 이루어지도록 할 순 없을까?

Payment
• 지불방식과 관계없이 하나의 함수만을 사용
• 하나의 콜과 콜백안에서 결제요청과 확인이 완료
• 지불수단 추가가 단순하고 쉬움
• 새로운 지불방식의 FLOW 를 공부해야 할 필요가 없음
우리가 기대하는 수준

Web Payment 를 이용하면 가능할지도

Web Payment 에 대한 오해
Web Payment
• 새로운 결제방식의 표준인가?
=> 아니다. 결제나 지불수단과 관련 없다.
• 결제와 관련된 새로운 인증기술을 제공하나?
=> 아니다. 결제 인증과 아무런 관련 없다.
• 웹 브라우저가 PG 역할을 대신해주는 것인가?
=> 결제 프로세스와 관련 없다.

그렇다면 Web Payment는 무엇일까?
Web Payment

Web Payment
Web Payment
• Payment Request API
=> 결제를 위한 프롬프트 UI 생성 / Payment Handler 로 구현된 결재 앱을 Activate 시킴
• Payment Handler
 서비스워커 형태로 결제앱을 구현 가능하게 해주는 것

Web Payment
Web Payment
• Payment Request API
=> 결제를 위한 프롬프트 UI 생성

Web Payment
Web Payment
• Payment Handler
 서비스워커 형태의 결제앱

Web Payment

PG 나 카드사의 결제사이트로 연결시켜 주는 것뿐이 아닐까?
Web Payment

Merchant 와 결재 앱간의 통신이 네트웍으로 노출되지 않는 특징
Web Payment
• 보안적으로 안전한 연결을 제공

기존 URL-Redirection 방식
Web Payment

피싱에 취약
Web Payment

결제인증과 요청 및 확인이 이원화되면서 구조가 복잡해짐
Web Payment

Payment
• 지불방식과 관계없이 하나의 함수만을 사용
• 하나의 콜과 콜백안에서 결제요청과 확인이 완료
• 지불수단 추가가 단순하고 쉬움
• 새로운 지불방식의 FLOW 를 공부해야 할 필요가 없음
우리가 기대하는 수준

기존의 웹 결제방식은 콜백구조가 어려운 경우들이 존재
Web Payment
1. URL-Redirection 으로 결제 페이지를 로드하는 경우
- 기존 Merchant 페이지의 스크립트들이 UNLOAD 되어 버림
2. iframe 으로 결제 페이지를 로드하는 경우
- Merchant 와 결제사이트의 Origin 이 서로 다르기 때문에 데이터에 직접 접근할 수가 없
다.

Payment Handler 의 경우
Web Payment
Web Browser
Merchant
ServiceWorker
PaymentHandler
Merchant 와 Pay앱이 서로 별개의 쓰레드이기 때문에 콜백구조가 깨지지 않는다.

하지만 결국 PG가 PaymentHandler 로 앱을 구현해야만 하는거 아닌가?
Web Payment

페이앱에서 기존 PG 사들의 FLOW를 구현
Web Payment
결제요청과 결과확인은 PG와 관계없이 PaymentRequest API 하나로 제공

Payment
• 지불방식과 관계없이 하나의 함수만을 사용
• 하나의 콜과 콜백안에서 결제요청과 확인이 완료
• 지불수단 추가가 단순하고 쉬움
• 새로운 지불방식의 FLOW 를 공부해야 할 필요가 없음
PaymentHandler 로 가능하다

6.
Future

Thank you