c i l b u Siirto & Open Payment Ecosystem - Tieto Payment Ecosystem project view c 4 WP In-store WP...

Pub

lic

Siirto & Open PaymentEcosystemeCommerce workshop 2

Tieto

© Tieto Corporation

Pub

licAgenda for Today• 12:00 - 12:15 Introduction• 12:15 - 12:30 Open Payment Ecosystem status• 12:30 - 13:30 CR candidate status• 13:30 - 13:50 Group work introduction

• 13:50 - 14:10 Break

• 14:10 - 15:00 Group work• 15:00 - 15:30 Group work presentations• 15:30 - 15:45 Questionnaire• 15:45 - 16:00 Closing and next steps

2

SolutionWS25.4


Pub

liceCommerce work package schedule

3

Teamset-up

& prepareDraft 01

JANUARY

Interview Inter

view

PresentInitial

Workflow(s)

DP1Interview

Interview

Interview

February

Finalizev1.0

workflows

InfosharingAB

SolutionWS1

Innovatenew userjourneys

IdeationWS

Draft 02Draft 01 V1.0

Agree nextsteps….

Agreeplan

Elabora-tionWS

Releasecandidata

End user stories /scenarios

Input:Indicative

Requirementsto Automatia

Input:CRs for

Automatia

Interview

DP0

DP2 DP4

How tocontinue?

April

Automatia decisionmaking process

March

DP3

Nextpriority?

AB

Interview

Interview

Interview

SolutionWS25.4


Pub

licOpen Payment Ecosystem project view

4

WPIn-store

WPeCommerce

Automatia

DEC JAN FEB MAR APR MAY JUN2017

MAY AUG

Advisory boardmeetings

Siito decion board

24.3

PILOTING

V1.23

2016

V1.24 & V1.25

1-on-1 meetings

WS1 info

WS2 flows

WS3 specs.

WS4 innovate

Next steps

Roadmap development

SEP

WPE-receipt

1-on-1 meetings

Pilot Tampere

WS1 flows

TaltioEU H2020 program?

WS1 flows

Proto

Test lab?

WS2 authn &e-address Pilot?

WS2 specs

Inno Days VR shop

Next steps

4.4.2.3.6.2. 4.4.

KaarleHonkamaa

MattiTimonen

SamiUski

JyriMarviala

FredrikJansson

Pub

lic

CR Walkthrough

5


Pub

licIdentified CR candidates

6

No Date Description Area Priority Requirement1 February

2017Acknowledgement message to Beneficiary PSPafter unsuccessful payment.

Paymentacknowledgement

Automatia to "notify" Registering PSP withacknowledgement message of unsuccessful paymentfollowed by a payment request. It would be useful alsoknow the reason why payment failed (eg. Insufficientfunds). In a eCommerce case PSP sending the paymentrequest would receive an acknowledgement if thepayment has failed.

2 February2017

Service for resolving payment request status Payment request Service for getting the payment request / payment statuson a basis of payment request id. It would be usefulalso know the reason why payment failed (eg.Insufficient funds).

3 March 2017 Support for refund Payment Payment initiation message should include linkage tooriginal payment / payment request, therefore currentparameters in payment initiation message are notsufficient for refund purposes. One refund may covermultiple orders/payments.

4 March 2017 Acknowledgements to support refunds Paymentacknowledgement

For refund purposes acknowledgement message shouldinclude all the mandatory information needed in paymentinitiation. At least LegalID information needs to be addedto acknowledgement-message as mandatoryinformation.

5 February2017

Authentication service Authentication Authentication service utilizing Siirto registry for theeCommerce purposes.


Pub


7

No Date Description Area Priority Requirement6 March 2017 Additional PIN/password to avoid misuse Authentication Linkage PIN/Password to proxy in order to avoid

misuse/spam.7 March 2017 Payment request metadata Payment

requestSupport for adding metadata to payment request.

8 March 2017 Possibility to specify payer to be someone else(eg. Parent)

Paymentrequest

Support for defining the payer (receiver of the paymentrequest) to be someone else than end customer visitingthe eCommerce site. Eg. Child is doing the purchaseand parent will pay it.

9 March 2017 Possibility to initiate payment request withBeneficiary BIC + IBAN

Paymentrequest

Service for sending payment request with BIC + IBANinstead of beneficiary procy information. This wouldremove the requirement for beneficiary registration toSiirto Registry.

10 February2017

Offering user Interfaces for Merchant PSPs Support Automatia to offer User Interfaces for Merchant PSPseg. Registry update / statistics / audit trail purposes.

11 February2017

Central data storage for delivery addresses eCommerce Central data storage for End customer's deliveryaddresses

12 February2017

Integration of loyalty programs to Siirto payment /Registry

eCommerce Siirto Registry to cover loyalty program / cardinformation.

13 February2017

eAddress for eReceipt eReceipt Service where proxy returns eAddress for eReceiptEnd Customer decides where eReceipt is sent, to somespecific service or by email/sms. Enabling update ofeAddress needs support from PSPs.


Pub


8

No Date Description Area Priority Requirement14 February

2017PISP cancelling the payment request. Ifpayment request is not processed can PISPcancel the payment request

Authentication

15 March 2017 BIC is required at registration and ARPPpayment. Could this requirement be removed?

Registration

16 February2017

Integration of loyalty programs to Siirto payments/ Registry

Pub

lic

Group work

9


Pub

licInstructions

• Answer questions listed in the following slides• 3 topics

• Siirto authentication• Shared delivery address register• Payment request handling

• Prepare 15 min presentation• Time 70 mins

Pub

lic

Siirto Authentication

11


Pub

licSiirto authentication• Option 1: support for verifying against Siirto Registry that person is a valid registered user. Possibly age

and/or SSN returned in a response• Option 2: Non-authenticated (non-signed in) user, information fetched from Siirto Registry with proxy + PIN• Option 3: User identified by pushing notification to user's Siirto app.• Option 4: Automatia will take intermediary role in network of trust

TASK FOR GROUP WORK:1. Analyse the feasibility from different perspectives

1. End user2. Merchant3. Regulatory4. Security

2. List pros and cons of each alternative

12


Pub

lic

Corporate Merchant PSP Originator’s PSP Automatia Beneficiary PSP Benefi-ciary

API Backend ChannelSystem

Transactionsystem

Siirtoregistry

ARPP AuthRequest

Accountvalidation

Transactionsystem

Channelsystem

SiirtoAuthrequest

Validaterequest

Processrequest

Share userinformation

Acknowledgestatus ofinformationsharing

Look-upuser

InitiateAuthRequest(NEWAUTHTYPE)

Option 1: validating registered userEndcustomer

With phone number

Login towebshop.

Loginsuccess.

Validatetheregistered user isvalid &over 18yo

FetchRequestedUser Data


Pub

lic



Transactionsystem

Siirtoregistry

ARPP AuthRequest

Accountvalidation

Transactionsystem

Channelsystem

SiirtoAuthrequest

Validaterequest Process

request



Look-upuser


Option 2: login with SiirtoEndcustomer

With phone numberLoginwith Siirtotowebshop(with pin).

Loginsuccess.



Pub

lic



Transactionsystem

Siirtoregistry

ARPP AuthRequest

Accountvalidation

Transactionsystem

Channelsystem

SiirtoAuthrequest

Authrorize(authn/sign)


request

PushRequestTo user

Approveinformationsharing



Look-upuser


Option 3: user consent for data sharingEndcustomer

With phone numberLoginwith Siirtotowebshop.

Confirmapproval

Loginsuccess.



Pub

licSiirto authenticationTASK FOR GROUP WORK:1. Analyse the feasibility from different perspectives

1. End user2. Merchant3. Regulatory4. Security

2. List pros and cons of each alternative

16

Pub

lic

Shared DeliveryAddress Register

17


Pub

licShared delivery address register

• Establish central data storage for end customer's delivery addresses tostreamline ecommerce checkout process

• Questions for group work• Need / business value?

• Improved checkout completion rate via speeding up the process?• Other benefits of having a shared delivery address register?

• Where to store the data, pros/cons?• Automatia registry• End user app• PSP via routing services• Other?

18


Pub

lic



Transactionsystem

Siirtoregistry

ARPP AuthRequest

Accountvalidation

Transactionsystem

Channelsystem

SiirtoDeliveryaddrrequest



request

PushRequestTo user

Approveinformationsharing



Look-upuser

InitiateAddrRequest(NEWAUTHTYPE)

E2E solution example: Obtain delivery addressEndcustomer

With phone numberEnterphonenumber

Confirmapproval

Addressshown.


Calculatefinal priceandproceedwithpaymentreq


Pub

licShared delivery address register

• Establish central data storage for end customer's delivery addresses tostreamline ecommerce checkout process

• Questions for group work• Need / business value?

• Improved checkout completion rate via speeding up the process?• Other benefits of having a shared delivery address register?

• Where to store the data, pros/cons?• Automatia registry• End user app• PSP via routing services

20

Pub

lic

Payment RequestHandling

21


Pub

licmCommerce payment request handling

1: Notification sending1. Bank’s app opened via notification2. Going back to payment app manually

2: Automatic switching between merchant app and bank’s app1. New query to check which bank’s mobile app and user device is installed2. Sending payment request from merchant app3. Bank app opened automatically & payment request appears without refresh needed4. After approval switching back to merchant app automatically

22


Pub

licPayment request handling

Does this add value compared to notification sending?What is the impact to current implementation?Level of standardization needed?

23

Pub

lic

CR Prioritization

24


Pub

licPrioritization of CRs

25

Number

CR

1 Separate API for eCommerce refunds. This is due different metadata requirements as payments will require

2 Linkage PIN/password to phone number to avoid misuse / spam

3 Return “not acknowledge –messages” in addition to “acknowledge message”. Verify what kind of information isto be / can be included with nack

4 Payment / payment request metadata. What kind of information can be attached to payment/payment request(that flows also to ack / nack). Consider required eReceipt flow and (partial) refunds linked with payments aswell.

5 PISP cancelling the payment request. If payment request is not processed can PISP cancel the paymentrequest

6 BIC is required at registration and ARPP payment

7 Develop Siirto authentication specification

8 Integration of loyalty programs to Siirto payments / Registry

9 Payment request metadata user experience specification on bank mobile application

10 Shared delivery addresses specification with Siirto registry

11 mCommerce switching between mCommerce app and banks security app

Pub

lic

Tieto

Pub

lic

Process flowsFrom the last workshop


Pub

lic

Corporate PISP Originator’s PSP Automatia Beneficiary PSP Benefi-ciary


Transactionsystem

Siirtoregistry

ARPP PaymentReqtuest

Accountvalidation

Transactionsystem

Channelsystem

RegisterEntity toSiirtoregister

Account IBAN & BIC & businesID and SiirtoIDRegisterPSP /MerchantTo Siirto

Register PSP/Merchant to Siirto

SenderID forPSP

MerchantPSP user

PSPregistringprocess


Pub

lic



Transactionsystem

Siirtoregistry


Accountvalidation

Transactionsystem

Channelsystem

Check-out


Paymentprocessing

DebitOriginatoraccount Credit

Beneficiaryaccount

NotifyOriginator

SETTLEMENTPROCESS

ManageACH

Validaterequest

Withdrawaltransaction

Deposittransaction

Acknow-ledgement


request

PushRequestTo user

Initiate thepayment

ManageACH

ManageACH

ConfirmCheck-out

Look-upFor BIC

NotifyBeneficiary

Route basedon BIC

With phone number and business IDInitiatePaymentrequest

eCommerce payment with Siirto payment request

Endcustomer

PaymentRequestStatus

GetPaymentRequestStatus

Withdrawal

Deposit


Pub

lic

Corporate PISP Originator’s PSP Automatia Beneficiary PSP Benefi-ciary


Transactionsystem

Siirtoregistry


Accountvalidation

Transactionsystem

Channelsystem

Routingservices

Paymentprocessing

DebitOriginatoraccount Credit

Beneficiaryaccount

NotifyOriginator

SETTLEMENTPROCESS

ManageACH

Validaterequest

Withdrawaltransaction

Deposittransaction

Acknow-ledgement

Initiate thepayment

ManageACH

ManageACH

ConfirmCheck-out

NotifyBeneficiary

Alt 2 - eCommerce refund with Siirto (C2B)

From Account IBAN & BIC toAccount IBAN & BIC

Validateaccount

Accountvalidation

Account IBAN & BIC

Withdrawal

Deposit

Pub

lic

Considered in work

31


Pub

licTo be considered in work

• Siirto Advisory Group requests• End-user authentication during the process• Linkage to potential loyalty program(s)• Payment request handling in bank's mobile app

• Other topics to consider• Merchant/merchant PSP initiating payment• Shared delivery address storage (e.g. beneficiary register)• mCommerce - phone number fetched from app


Pub

licIdentified CR candidates in previousmeeting

33

Number CR

1 Separate API for eCommerce refunds. This is due different metadata requirements as payments will require

2 Linkage PIN/password to phone number to avoid misuse / spam

3 Return “not acknowledge –messages” in addition to “acknowledge message”. Verify what kind of information is tobe / can be included with nack

4 Payment / payment request metadata. What kind of information can be attached to payment/payment request (thatflows also to ack / nack). Consider required eReceipt flow and (partial) refunds linked with payments as well.

5 PISP cancelling the payment request. If payment request is not processed can PISP cancel the payment request

6 BIC is required at registration and ARPP payment. Could this requirement be removed?

7 Develop Siirto authentication specification

8 Integration of loyalty programs to Siirto payments / Registry

9 Payment request metadata user experience specification on bank mobile application

10 Shared delivery addresses specification with Siirto registry

11 mCommerce switching between mCommerce app and banks security app

Date post:	24-May-2018
Category:	Documents
Upload:	truongmien
View:	218 times
Download:	5 times

c i l b u Siirto & Open Payment Ecosystem - Tieto Payment Ecosystem project view c 4 WP In-store WP...

Documents