1.5. Sale Form

Introduction

Sale is a type of transaction, in which Payer receives goods or services from Connecting Party in exchange for money or other assets. Sale Form integration allows Connecting Party to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Billblend hosted payment form in PCI DSS certified environment.

All forms can be customized. Follow the Forms Customization reference to see examples and macros of Payment Page Customization, Prefilled Cardholder Data in Payment Page, Wait Page Customization and Finish Page Customization.

See terms definitions in Glossary.

Sale Form Flow

  @startuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
actor Payer as Customer
participant "Connecting Party\nwebsite" as Merchant
participant "Payment Gateway" as g
autonumber
Customer -> Merchant: Checkout
activate Merchant
== Purchase payment request ==
Merchant -> g: api/v2/sale-form
activate g
g --> Merchant: Redirect-url, orderId
deactivate g
Merchant -> Customer: Provide redirect-url \nto payer’s browser
deactivate Merchant
activate Customer
Customer -> g: GET redirect-url
deactivate Customer
activate g
g --> Customer: Payment Form
deactivate g
activate Customer
Customer -> g: Submit form
deactivate Customer
activate g
g --> g: Process payment
== Final redirect of customer ==
g -> Customer: Connecting Party website redirect_url
activate Customer
Customer -> Merchant: POST redirect_url\nstatus, orderid
deactivate Customer
activate Merchant
group Get Final Status
== Receive Connecting Party Callback ==
Merchant <- g: Сallback with final status
g <-- Merchant: HTTP 200
deactivate g
== Order Status Request ==
Merchant -> g: api/v2/status
activate g
g --> Merchant: Response \nstatus, order-stage
deactivate g
end
Merchant --> Customer: Show result
deactivate Merchant
@enduml

(2) To implement sale-form request see /api/v2/sale-form/.

(9) To implement final redirect see Final Redirect.

(11,12) To implement callback with final status handling see Connecting Party Callbacks.

(13) To implement order status request see /api/v2/status/. Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

Contact us

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