1.20. Mobile Device Transfer

Introduction

Mobile device transfer can be performed with cardholder data of sender and receiver of funds or with card reference, previously made withΒ card verificationΒ process or in previous transfer/sale transactions.

See terms definitions inΒ Glossary.

Transfer Flow

@startuml
autonumber
title Mobile Device - 3-D Secure card funds transfer
skinparam ParticipantPadding 70
participant "Consumer" as client
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Billblend" as company
client <-> mobile: Authentication
mobile -> party: Request access token
mobile <-- party: Response access token
note right
accessToken
end note
mobile -> party: Initiate transfer request
mobile <-- party: Initiate transfer response
mobile -> company: Perform transfer request
mobile <-- company: Perform transfer response
note right
session token
end note
party <- company : Check transfer request
party --> company : Check transfer response
company -> company: Start processing
mobile -> company: Transfer status request
note left
session token
end note
mobile <-- company: Transfer status response
note right
state = REDIRECT_REQUEST
end note
mobile -> mobile: Open browser and provide \nredirectUrl to redirect to 3DS page
activate mobile
client <-- mobile: Provide redirectUrl
client -> mobile: The cardholder provides auth data
mobile -> company: Transfer status update
company --> mobile: Close browser request
destroy mobile
company -> company: Process transfer
    party <- company: Transfer card mapping notification request
note right
server card id
end note
    party --> company: Transfer card mapping notification response
mobile -> company: Transfer status request
note left
session token
end note
mobile <-- company: Transfer status response
note right
bankorder id
state = APPROVED|DECLINED
end note
party <- company: Callback with final status request
party --> company: Callback with final status response
@enduml

(1,2,3) To perform authentication of Consumer in Connecting Party’s app, Connecting Party can use any method which fits best to their needs. As a result, Connecting Party’s server generatesΒ {accessToken}Β and provides it to Connecting Party’s app. This parameter will be used to start and continue session.

(4,5) To initiate funds transfer, Connecting Party’s app sendsΒ {accessToken}Β with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique randomΒ {nonce}Β and encryptedΒ {signature}. To initiate transfer request seeΒ Initiate Transfer.

(6,7) On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Billblend to perform funds transfer from card to card. To implement perform transfer request seeΒ Perform Transfer.

(8,9) Check transfer is used for security purposes and allows Billblend to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check transfer request seeΒ Check Transfer.

(11,12,21,22) Funds transfer status request is made by Connecting Party’s app to Billblend to get the status of transfer transaction. To implement transfer status request seeΒ Status Transfer.

(19,20) Billblend sends Transfer card mapping notification request to Connecting Party’s server/proxy with created on its side card reference –Β {serverCardId}. To implement transfer card mapping notification request seeΒ Transfer card mapping notification.

(23,24) Connecting Party specified a callback URL, Payment Gateway sends message to the callback URL whenever transaction reaches final status, no matter if the result isΒ approved,Β declinedΒ or otherΒ final status. See moreΒ Callbacks.

Repeat Transfer Flow

After successful Card mapping procedure, new transfers with the same cardholder data can be done easier for Consumer.

Connecting Party’s app makes new transfer requests usingΒ {clientCardId}Β instead of source and/or destination cardholder data. Billblend sends theseΒ {clientCardId}Β to Connecting Party’s server in β€œCheck transfer request” and gets mapped to itΒ {serverCardId}Β in β€œCheck transfer response” from Connecting Party’s server. TheseΒ {serverCardId}Β are used to continue the processing of transfer transaction.

Transaction flow remains the same:Β Initiate TransferΒ ->Β Perform TransferΒ ->Β Check Transfer.

If there is no need to change Consumer’s data (such as address, phone, etc.), β€œPerform transfer request” for Repeat transfer may be sent without any optional parameters and with card references for sender and receiver instead of cardholder data. If Consumer’s data has to be changed, new source card reference must be created.

If source and/or destinationΒ {clientCardId}Β are used in β€œPerform transfer request”, source and/or destinationΒ {serverCardId}Β must be included in β€œTransfer check response” and signature.

If sourceΒ {clientCardId}Β was mapped toΒ {serverCardId}Β in transaction with includedΒ {consumer.email}Β value, new β€œPerform transfer request” and β€œCheck signature response” with thisΒ {clientCardId}Β must also contain the sameΒ {consumer.email}Β value.

For Repeat Transfer Flow use the following source of funds parameters in Perform Transfer request:

  1. {sourceOfFunds.reference.clientCardId}
  2. {sourceOfFunds.reference.securityCode}

Instead of:

  1. {sourceOfFunds.card.expiry.month}
  2. {sourceOfFunds.card.expiry.year}
  3. {sourceOfFunds.card.holder}
  4. {sourceOfFunds.card.holder.firstName}
  5. {sourceOfFunds.card.holder.lastName}
  6. {sourceOfFunds.card.number}
  7. {sourceOfFunds.card.securityCode}

For destination of funds useΒ {destinationOfFunds.reference.clientCardId}Β instead ofΒ {destinationOfFunds.card.number}.

@startuml
autonumber
title Mobile Device - Card references for Repeat transfer
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Billblend" as company
skinparam ParticipantPadding 80
== Last part of card verification or transfer ==
party <- company: Card mapping notification request
note right
serverCardId
end note
party --> company: Card mapping notification response
party --> party: Create clientCardId for serverCardId
party -> mobile: Store reference in app or send it by request
note right
clientCardId
end note
== New transfer ==
mobile -> party: Initiate transfer request
mobile <-- party: Initiate transfer response
mobile -> company: Perform transfer request
note left
clientCardId
end note
mobile <-- company: Perform transfer response
party <- company: Check transfer request
note right
clientCardId
end note
party --> company: Check transfer response
note left
serverCardId
end note
company -> company: Process transfer
@enduml

(1,2) Billblend sends Transfer card mapping notification request to Connecting Party’s server/proxy with created on its side card reference –Β {serverCardId}. To implement transfer card mapping notification request seeΒ Transfer card mapping notification.

(5,6) To initiate funds transfer, Connecting Party’s app sendsΒ {accessToken}Β with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique randomΒ {nonce}Β and encryptedΒ {signature}. To initiate transfer transfer request seeΒ Initiate Transfer.

(7,8) On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Billblend to perform funds transfer from card to card. To implement perform transfer request seeΒ Perform Transfer.

(9,10) Check transfer is used for security purposes and allows Billblend to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check transfer request seeΒ Check Transfer.

Consumer Defined Transfer Rates Flow

Consumer defined transfer rates is an optional feature which allows the sender to choose the most suitable commission amount for his transfer transaction between several available payment provider gates.

The possibility of such feature depends on the integration. Please ask support manager for details.

When such feature is enabled, the Transfer Flow extends:

  1. If Check transfer has been successful, Billblend pauses the processing, includes the list of possible commissions to next Transfer status response and awaits for confirmation from the Consumer.
  2. Consumer selects the most suitable commission from the list in the Connecting Party’s app.
  3. Connecting Party’s app sends the selected gate (using itsΒ assignedIdΒ aliased name) in Complete transfer request to Billblend.
  4. Billblend continues to process the transaction on the selected gate.
@startuml
autonumber
title Consumer defined transfer rates
participant "Consumer" as client
participant "Mobile App" as mobile
participant "Billblend" as company
== Transfer has been checked successfully ==
company -> company : Pause the transaction
loop until Complete transfer is sent
mobile -> company: Transfer status request
note left
session token
end note
mobile <-- company: Transfer status response
note right
state=TRANSFER_FEE_REQUEST
transferFeeList
end note
end
mobile -> client: Ask to select the commission
mobile <-- client: Commission selected
mobile -> company: Complete transfer request
    note left
    assignedId
    end note
mobile <-- company: Complete transfer response
company -> company: Continue processing
@enduml

(2,3) Funds transfer status request is made by Connecting Party’s app to Billblend to get the status of transfer transaction. To implement transfer status request seeΒ Status Transfer. Transfer status response includes theΒ stateΒ parameter withΒ TRANSFER_FEE_REQUESTΒ value and theΒ transferFeeListΒ object with a list of commissions for possible processing gates. Each processing gate is represented by it’s own aliased name inΒ assignedIdΒ parameter.Β TRANSFER_FEE_REQUESTΒ value inΒ stateΒ parameter exists only in β€œConsumer defined transfer rates” flow. The mentioned parameters may not be presented in first Transfer status response, so Connecting Party’s app should continue polling the transaction status. When the transaction reachesΒ TRANSFER_FEE_REQUESTΒ state, the processing will remain paused until Complete transfer request is sent.

(6,7) To implement Complete transfer request seeΒ Complete transfer.

Contact us

Contact us in Telegram

By clicking on the button, you agree to theΒ data protectionΒ policy

Complete the quiz

By clicking on the button, you agree to theΒ data protectionΒ policy