Quick Start to Integrating Stripe in Your Application

After the user is redirected to the checkout session, Stripe provides a preferred form of payment. Upon successful payment, the client is redirected to the success_url of your site. If the payment was not completed, the user will be redirected to the exit_url and will get to the same page that led to the checkout before.

After successful payment, the session will provide a link to the client. This link will get them back to the app. The user will also receive the details of the payment method or their subscription plan. Note that the checkout session expires in 24 hours. Do not rely on redirecting to success_url after completing the purchases as attackers can gain direct access to success_url or users will not always be able to achieve success_url after the payment. 

Once the Checkout session is successfully completed, there are two ways to get the Session object:

1. Asynchronously: handle ‘checkout.session.completed’ webhooks that contain a Session object ;

2. Synchronously: get sessionId URL when the user is redirected back to your site. However, this may not always happen: for example, if the user closes the browser tab before the redirection happens. Working with webhooks prevents this form of dropout.

A subscription is created by combining a customer and a product. After placing the order, the user is invited to pay the bill. If the card was not entered before, you must create a new ‘card’ object in Stripe. Subscriptions allow you to charge a customer on a recurring basis. If a one-time purchase is made, instead of an object Subscription, the Charge object is created. 

Add Charge using Stripe library:

Or create a Subscription using Stripe library:

You can also configure webhooks to receive notifications about events that happen in your account. The endpoint must have an URL and a list of enabled_events. If you wish, you can specify the connection parameter too. If its value is true, you will receive notifications to the specified URL about all events from all connected accounts. If its value is false, notifications about your account will be sent to the specified URL only. 

Usually, webhooks are configured in the Stripe toolbar. But you can use the API to create an object:

Payments 

When you create a payment in Stripe, a security token is created that you can use only once. In order not to request the card data every time, Stripe creates a Custom object. You can use it for subscriptions or for one-time payments. To make the card available for other payments, it is necessary to create a Custom object instead of a Charge object and save the client’s identifier.

In order to debit from a specific client, you just need to pass the identifier instead of the card data in the debit request. Stripe also has a system for automatically updating the card data if the card was reissued by the bank (in case of its loss, replacement due to the validity period, etc.). However, the option of automatic data update depends on the bank’s participation in the Stripe network and the provision of this data. This feature is widely used in America and allows customers to continuously use the service.

Clients can use several payment methods and the first saved one will be selected as the default_source and will be used every time a subscription payment is made. As for creating and deleting a card, it is also possible to update the client’s data and selecting another card as the default one.

Transactions

Transactions are cash flows resulting from approved permits and actions of the cardholder. They are created when the card is used to send or to receive money. Transactions contain information about the card used, the cardholder, and the seller.

Sometimes after authorization is approved, the merchant will retain its monetary amount for a period of time. In most cases, it happens within 24 hours, although the retention may take up to 7 days. Most merchants won’t be allowed to retain this monetary amount for longer than 7 days, although a few merchant categories (including hotels, airlines, and car rental companies) have up to 30 days of retention. 

When authorization is retained, two things happen at the same time:

• The status of the Authorization object changes to closed and releases the purchase amount held by that authorization. A balance transaction of type “issuing_authorization_release” is created to represent this. In addition, an ‘issuing_authorization.updated’ webhook event is triggered.

• A new Transaction object of the “retention” type is created. It deducts the purchase amount from your account balance. Another balance transaction of type “issuing_transaction” is created to represent this. In addition, an “issuing_transaction.created” webhook event is triggered.

Both refunds (in case of legitimate transactions) and credits (in case of accidentally-duplicated captures from the acquirer) result in transactions with a type of refund. Refunds may also be reversed (in case of duplicated refunds from the acquirer), which results in a transaction with a “refund_reversal” type.

When we create a transaction representing a refund, a credit, or a refund reversal, we try to link it to the original authorization. But sometimes this isn’t possible. In these cases, the authorization field of the transaction is set to null and the transaction won’t be linked to the authorization in the Issuing dashboard.

The Issuing transactions dashboard lists all transactions across all issued cards, providing details such as:

• Amount;

• Card used;

• Cardholder name;

• Date;

• Description;

• Merchant category.

You can filter which transactions you want to see by specifying the ID of an issued card or you can download all transactions as a CSV file.

You can also retrieve transactions by using the API to develop and generate custom reports. For example, you can retrieve transactions to generate a typical credit card statement by listing all transactions within a certain period of time (e.g., 30 days) for a particular card.

A list can include a maximum of 100 objects. If you need to retrieve more transactions, use pagination to perform additional requests.

Transactions usually contain the ID of their original authorization in the authorization field. In some cases, when including refunds or a force-cleared purchase, there isn’t an authorization that a transaction can link to. In this case, the authorization field has a null value.

You can also include pending purchases in your statements by listing authorizations that have a pending status. These authorizations hold funds but were not yet captured. As a result, no transactions were created for them yet.