At this point, you probably know that @Pay allows customers to use their email in the same way they would use a credit card. This page will build on that knowledge and outline the typical @Pay transaction flow, along with the associated API calls that are made.
Before we dive into the traditional flow, we should go over a few terms that will be used throughout this document. * +Token+: A value that contains information about a financial transaction (an invoice or a product sales offer, for instance). * +Card Registration+: The process of registering a card with @Pay for future use. * +Payment Capture Page+: A page that the customer is directed to in order to enter their payment information for card registration.
The typical @Pay Flow is structured in the following way:
As you can see from the outlined flow, there are three main points where the @Pay API is utilized: Token creation, Card Registration, and Transaction Processing.
Available Clients: Ruby, PHP Tokens can be generated programmatically by both the Ruby and PHP clients. These tokens contain information about the merchant, the transaction amount, and the customer’s e-mail address (if applicable). Detailed information on generating a token can be found in our Ruby Documentation and our PHP Documentation.
Once a token is generated, it can be utilized to create transactions.
Available Clients: @Pay.js Card registration is necessary when a card is not currently associated with an e-mail address. Should this case arise, your site may register the card on behalf of the customer using @Pay.js. For examples on this operation, you can view our page on registering cards.
Available Clients: @Pay.js Should your site ever need to charge the card directly without a token, you may initiate transactions direcly through the use of @Pay.js. For examples on this operation, you can view our @Pay.js documentation.