Payment Integration
Vitayou currently integrates with Paratika as its main payment provider.
Since they do not provide any modern or easy to understand SDK for neither backends or frontends, we had to write one.
Service Access
Paratika providers both a sandbox and a production environment.
| Name | URL |
|---|---|
| Docs | https://entegrasyon.paratika.com.tr/paratika/api/v2/doc |
The Service
The service is placed under app/Services/Payment relative to the project root. The service is written using strategy pattern and with this approach, you can easily write another strategy without changing much of the code in case the service needs replacement.
Tip
Active strategy can be replaced by changin the PAYMENT_GATEWAY environment variable.
The Structure
Payment
├── Contracts
│ └── PaymentServiceGatewayContract.php
├── Gateways
│ ├── Mock
│ │ ├── Listeners
│ │ │ └── RefundAcceptedListener.php
│ │ ├── Services
│ │ │ ├── MockData.php
│ │ │ └── MockService.php
│ │ ├── MockGateway.php
│ │ ├── MockServiceFactory.php
│ │ └── Routes.php
│ └── Paratika
│ ├── Entities
│ │ ├── ParatikaDTO.php
│ │ ├── Paratika***DTO.php
│ ├── Exceptions
│ │ ├── ParatikaCardQueryException.php
│ │ ├── ParatikaClientException.php
│ │ ├── ParatikaPaymentException.php
│ │ └── ParatikaSessionException.php
│ ├── Listeners
│ │ └── RefundAcceptedListener.php
│ ├── Services
│ │ ├── Core
│ │ │ ├── ServiceCore.php
│ │ │ └── ServiceResolver.php
│ │ ├── ServiceFactory.php
│ │ ├── ***Service.php
│ │ └── Utilities.php
│ ├── ParatikaClient.php
│ ├── ParatikaGateway.php
│ └── Routes.php
└── PaymentService.phpAll of the available and used endpoints are reflected as a Paratika Service.
Operations and queries are done with robust DTO object generators (under Entities).
The Repository
The PaymentRepository is a very minimal one that is only used for generation of session tokens.
It is wise to move all relevant code into the repository in the upcoming development cycles.
How it works in a nutshell
The Paratika service is integrated with 3d secure approach in order to maximize security and recurrance of saved payment methods.
The actual payment requests are done to the Paratika endpoint with the following steps:
- Create a session token (Vitayou Storefront -> Vitayou API)
- Make 3d secure payment (Vitayou Storefront -> Paratika)
- Place order (Vitayou Storefront -> Vitayou API)
- Synchronize orders, payments and subscriptions with relevant data (Vitayou API <-> Paratika)
To understand how the payment process actually works, please refer to the Storefront section.
Recurring Payments
The recurring payments are handled by storing a Paratika card token in the payment_methods table and run the RunSubscriptionsJob every day.
The RunSubscriptionsJob simply looks in the subscriptions table for the subscription records with next_cycle value same as the current date and creates orders for each of them.
But this time the payment is not done via regular credit card forms but instead the card token stored within the payment_methods.
Card Renewals
A job called ExpiringCardsJob is configured to run every month to look for cards with expiry dates are either next month or the month.
If exists, then the job sends an email to the owners of the relevant cards to remind them for the renewal to keep the subscription payments going.
Card Updates
Paratika only allows to update the expiry date and the alias name of an existing payment method.
When a card expires, the customer must create a new payment method either via placing a new order or by visiting their accounts in the Payment Methods section in the Storefront profile page.
Tip
However, when we send an e-mail to the customer, we store the new card information, update all the subscriptions belonging to the old method to use this new method, and then delete the old payment method.
Environment Variables
PAYMENT_GATEWAY=Paratika
PARATIKA_MERCHANT_ID=
PARATIKA_MERCHANT_USER=
PARATIKA_MERCHANT_PASS=
PARATIKA_MODE=testTesting
The payment service has a Mock strategy which is used when commencing unit and feature tests within PHPUnit suite.
