Download the PHP package atlpay/php-sdk-v2 without Composer
On this page you can find all versions of the php package atlpay/php-sdk-v2. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Informations about the package php-sdk-v2
ATLPay PHP SDK for APIv2
PHP Wrapper for ATLPay API Version 2
Table of Contents
- Requirements
- Installation and Usage
- Dependencies
- Getting Started
- Error Handling
- Tokens
- Creating a Token
- Retrieving a Token
- Creating a Charge
- Retrieving a Charge
- Cancelling a Charge
- Capturing a Charge
- Creating a Refund
- Custom Request Timeouts
- SSL / TLS compatibility issues
- Test Cards
Requirements
PHP 5.5.28 and later.
Installation and Usage
You can install the bindings via Composer. Run the following command:
To use the bindings, use Composer's autoload:
Dependencies
The bindings require the following extension in order to work properly:
ext_curl
, although you can use your own non-cURL client if you preferext_json
ext_mbstring
(Multibyte String)
If you use Composer, these dependencies should be handled automatically. If you install manually, you'll want to make sure that these extensions are available.
Getting Started
ATLPay APIv2 is synchronized API and provides instant confirmation thus it does not require notification url. Any status returned by API should be considered final. Simple usage looks like:
Error Handling
ATLPay uses conventional HTTP response codes to indicate the success or failure of an API request. In general: Codes in the 2xx
range indicate success. Codes in the 4xx
range indicate an error that failed given the information provided (e.g., a required parameter was omitted, a charge failed, etc.). Codes in the 5xx
range indicate an error with ATLPay's servers (these are rare).
Some 4xx
errors that could be handled programmatically (e.g., a card is declined) include an error code that briefly explains the error reported.
HTTP status code summary
HTTP Status Code | Description |
---|---|
200 | Everything worked as expected. |
400 | The request was unacceptable, often due to missing a required parameter. |
401 | No valid API key provided. |
402 | The parameters were valid but the request failed. |
403 | You are not authorized to perform this transaction. |
404 | The requested resource doesn't exist. |
500, 502, 503, 504 | Something went wrong on ATLPay's end. (These are rare.) |
Tokens
Tokenization is the process ATLPay uses to collect sensitive card or personally identifiable information (PII), directly from your customers in a secure manner. A token representing this information is returned to your server to use. You should use ATLPay.js or our mobile libraries to perform this process, client-side. This ensures that no sensitive card data touches your server, and allows your integration to operate in a PCI-compliant way.
If you cannot use client-side tokenization, you can also create tokens using the API with secret API key. Keep in mind that if your integration uses this method, you are responsible for any PCI compliance that may be required, and you must keep your secret API key safe. Unlike with client-side tokenization, your customer's information is not sent directly to ATLPay, so we cannot determine how it is handled or stored.
Tokens cannot be stored or used more than once.
Creating a Token
Client Side
Creating token using ATLPay.js is described here.
Server side
Retrieving a Token
Creating a Charge
Retrieving a Charge
Cancelling an Authorized Charge
Capturing a Charge
Creating a Refund
ATLPay lets you do partial and full refunds. It also allows you to process multiple partial refunds.
A) Creating partial refund
B) Creating full refund
Custom Request Timeouts
NOTE: We do not recommend decreasing the timeout for non-read-only calls (e.g. charge creation), since even if you locally timeout, the request on ATLPay's side can still complete.
SSL / TLS compatibility issues
ATLPay's API now requires that all connections use TLS 1.2. Some systems (most notably some older CentOS and RHEL versions) are capable of using TLS 1.2 but will use TLS 1.0 or 1.1 by default. In this case, you'd get an BAD_REQUEST error with the following error message: "ATLPay no longer supports API requests made with TLS 1.0. Please initiate HTTPS connections with TLS 1.2 or later.
The recommended course of action is to upgrade your cURL and OpenSSL packages so that TLS 1.2 is used by default, but if that is not possible, you might be able to solve the issue by setting the CURLOPT_SSLVERSION
option to either CURL_SSLVERSION_TLSv1
or CURL_SSLVERSION_TLSv1_2
:
Test Cards
Following test cards can be used for testing ATLPay API
Card Number | Brand | Funding Type | Issuer Country |
---|---|---|---|
5555 5555 5555 4444 | MasterCard | Credit | GB |
5454 5454 5454 5454 | MasterCard | Debit | FR |
5555 5555 5555 4443 | MasterCard | Credit | GB |
5454 5454 5454 5453 | MasterCard | Debit | GB |
6759 6498 2643 8450 | Maestro | Debit | GB |
4444 3333 2222 1111 | Visa | Credit | FR |
4462 0300 0000 0000 | Visa | Debit | IN |
4444 3333 2222 1112 | Visa | Credit | FR |
4462 0300 0000 0001 | Visa | Debit | FR |
All versions of php-sdk-v2 with dependencies
ext-json Version >=1.2
ext-mbstring Version >=0.0.0