1.3. 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 GitPay 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.