PHPackages payvision/payvision-sdk-php - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Payment Processing](/categories/payments) 4. / 5. payvision/payvision-sdk-php ActiveLibrary[Payment Processing](/categories/payments) payvision/payvision-sdk-php =========================== Payvision PHP SDK 8.2.0(4y ago)511.9k2[1 issues](https://github.com/payvision-development/payvision-sdk-php/issues)MITPHPPHP ~7.1.3||~7.2.5||~7.3.0||~7.4.0CI failing Since Mar 7Pushed 4y ago2 watchersCompare [ Source](https://github.com/payvision-development/payvision-sdk-php)[ Packagist](https://packagist.org/packages/payvision/payvision-sdk-php)[ RSS](/packages/payvision-payvision-sdk-php/feed)WikiDiscussions master Synced 4d ago READMEChangelog (10)Dependencies (8)Versions (21)Used By (0) Payvision PHP SDK ================= [](#payvision-php-sdk) > Codebase for Payvision PHP SDK This is the official PHP SDK for the Payvision payment platform (). It can be used to make use of the following features of the Payvision API: - Payments - Make payment requests - Make capture requests - Make cancel requests - Make refund requests - Get transaction status updates - Paymentlink - Make new paymentlink - Get status of existing paymentlink - Cancel existing paymentlink - Checkout - Initialize new checkout - Get checkout status - Webhooks - Convert RAW webhook data to the proper objects Install ------- [](#install) This package can be installed using Composer: ``` composer require payvision/payvision-sdk-php ``` Usage ----- [](#usage) ### Initialize the API [](#initialize-the-api) To initialize the API Connection, refer to the following code snippet: ``` use Payvision\SDK\Infrastructure\ApiConnection; $apiConnection = new ApiConnection( 'username', 'password', ApiConnection::URI_TEST, // =URL to connect to, optional false // debug mode, see debugging ); ``` #### Debugging the API [](#debugging-the-api) The API uses the [Guzzle HTTP Client](http://docs.guzzlephp.org/en/stable/). The debug-property is passed through to the Guzzle Client. See for more information about debugging. ### Creating a request [](#creating-a-request) The PHP SDK is a direct reflection of how the JSON structure of the requests and responses are typically built for the Payvision API. For example, a typical payment request to the Payvision API would require a JSON body like this: ``` { "header" : { "businessId" : "{businessId}" }, "action" : "authorize", "body" : { "card" : { "holderName" : "John Doe", "number" : "4111111111111111", "expiryMonth" : "03", "expiryYear" : "2020" }, "transaction" : { "amount" : "1.00", "brandId" : "1010", "trackingCode" : "7F4BFD5D-55E4-4775-81F7-0784188876C7", "currencyCode" : "EUR" } } } ``` To create this identical request using the PHP SDK, you can use one of the composite builders: ``` use Payvision\SDK\Domain\Payments\Service\Builder\Composite\Payment\Request as PaymentRequestBuilder; use Payvision\SDK\Domain\Payments\ValueObject\Payment\Request as PaymentRequest; /** @var $paymentRequestBuilder PaymentRequestBuilder */ $paymentRequestBuilder->header()->setBusinessId('{businessId}'); $paymentRequestBuilder->body()->card() ->setHolderName('John Doe') ->setNumber('4111111111111111') ->setExpiryMonth(3) ->setExpiryYear(2020) $paymentRequestBuilder->body()->transaction() ->setAmount(1.00) ->setBrandId(1010) ->setTrackingCode('7F4BFD5D-55E4-4775-81F7-0784188876C7') ->setCurrencyCode('EUR'); $paymentRequestBuilder->setAction(PaymentRequest::ACTION_AUTHORIZE); $requestObject = $paymentRequestBuilder->build(); ``` At this point, you have a PHP representation of the JSON object that is to be sent to the API, but it is not yet the actual request. For example: we still need to know the URL where it needs to be sent to, and what kind of response we can expect from the API. To do this we need to transform our payment request to an API request: ``` use Payvision\SDK\Application\Payments\Service\RequestBuilder; $apiRequest = RequestBuilder::newPayment($requestObject); ``` Now we have an API Request that we can execute using our API Connection: ``` $requestHeaders = []; // Optional request headers $apiResponse = $apiConnection->execute($apiRequest, $requestHeaders); ``` #### About builders [](#about-builders) It is **strongly recommended** that you always use the builders provided by the SDK to create your objects, and never directly instantiate them. The reason behind this is that the method signature of the constructor call of a value object can change quite often as the API specification grows. This can quickly lead to backward compatible breaking changes in your code. Builders overcome this problem by abstracting the creation of value objects. And they're also a lot cleaner to work with. #### Handling an array as response [](#handling-an-array-as-response) Some API endpoints will not return a single object, but rather an array of objects. The [GET payments](https://developers.acehubpaymentservices.com/v3.3/reference#get-payment-by-tracking-code-2)endpoint is an example of this. In this case, where you as a developer know that you can expect an array as a result, you need to use the `ApiConnection::executeAndReturnArray()`-method instead of the `execute()`-method: ``` $apiRequest = RequestBuilder::getPayments($businessId, $trackingCode); $apiResponses = $apiConnection->executeAndReturnArray($apiRequest); $apiResponse = $apiResponses[0]; // for example ``` ### Handling the responses [](#handling-the-responses) The `$apiResponse` in the above example is an object of the type that is defined in the request. To know what kind of type this is, you can use `$apiRequest->getResponseObjectByStatusCode(200)`. If the API returns a non-2XX status, an exception is thrown of the type `Payvision\SDK\Exception\Api\ErrorResponse`. This exception has the error object with more information about what went wrong: ``` try { $apiResponse = $apiConnection->execute($apiRequest); } catch (ErrorResponse $errorResponseException) { /** \Payvision\SDK\Domain\Payments\ValueObject\Payment\Response $apiResponse */ $errorResponse = $errorResponseException->getErrorResponse(); } ``` Webhooks -------- [](#webhooks) Webhooks can also be handled by the SDK. In order to do so you need the following input data: - The Event Signature (also known as a Json Web Token (JWT). This is sent in the header) - The secret that is used to sign the JWT - The body of the webhook (as string). You can pass this data to the `EventBuilder` service of the webhook: ``` use Payvision\SDK\Application\Reflection\JsonToObject; use Payvision\SDK\Application\Webhook\Service\EventBuilder; use Payvision\SDK\Domain\Webhook\Service\Validator; $eventBuilderService = new EventBuilder( new Validator(), new JsonToObject() ); $event = $eventBuilderService->generateEvent( 'event signature', 'secret', 'json body' ); ``` Since the payload of the webhook event can be a variety of objects, the `Event::getPayload()` cannot be type-hinted. So you might want to do some extra checks on this: ``` $payload = $event->getPayload(); if ($payload instanceof \Payvision\SDK\Domain\Payments\ValueObject\Response\Request) { ... } ``` If you don't want this (because it might miss auto-completion in your IDE because of this), you can also use `EventBuilder::generateDecoratedEvent()` to get a `EventDecorator`that provides extra functionality so you don't have to guess what the payload is: ``` $decoratedEvent = $eventBuilderService->generateDecoratedEvent( 'event signature', 'secret', 'json body' ); if ($decoratedEvent->getPayloadType() === \Payvision\SDK\Domain\Webhook\Service\EventDecorator::TYPE_PAYMENT) { $payload = $decoratedEvent->getPaymentResponse(); } ``` The decorator also has some additional checks to make sure that the payload is known. Developer information --------------------- [](#developer-information) If you want to analyze or improve this SDK, it's good to read the following information, targeted at developers: ### Architecture [](#architecture) The SDK is setup in a Domain Driven way. At the core are Value Objects, which are the stateless, immutable building blocks that are used in the API. Value Objects can have other value objects as child-properties. Top-level Value Objects (like a Payment Request) are converted to API request objects, which are send to the API, which in turn returns a response object. Logic goes from bottom to top, dependencies go from top to bottom: ``` +-------------------+ | Value Object | Example: Transaction, Bank, Card, etc. | | These can be built manually, or by using the (composite) builders +-------------------+ ↓ Request Builder Builds request out of aggregate using reflection. ↓ +-------------------+ | Request | +-------------------+ ↓ API Client Does the request to the external API ↓ Response Builder Generates a response object out of the API response data using reflection. ↓ +-------------------+ | Response | Example: PaymentResponse +-------------------+ ``` ### Troubleshooting [](#troubleshooting) See Troubleshooting.md ### Contributing [](#contributing) If you have an issue or a feature request, feel free to create an issue. If you want to contribute to this code, you can send a pull request. License ------- [](#license) See LICENSE.txt ### Health Score 34 — LowBetter than 77% of packages Maintenance16 Infrequent updates — may be unmaintained Popularity25 Limited adoption so far Community11 Small or concentrated contributor base Maturity69 Established project with proven stability Bus Factor1 Top contributor holds 66.7% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~43 days Recently: every ~50 days Total 20 Last Release 1801d ago Major Versions 3.0.0 → 4.0.02020-01-15 4.1.1 → 5.0.02020-08-19 4.2.0 → 6.0.02020-11-19 6.0.0 → 7.0.02020-12-22 7.0.0 → 8.0.02021-02-09 PHP version history (4 changes)1.0.0PHP ^7.0.13|^7.1 5.0.0PHP ^7.2.5|^7.3 4.2.x-devPHP ~7.1.3||~7.2.0||~7.3.0 6.0.0PHP ~7.1.3||~7.2.5||~7.3.0||~7.4.0 ### Community Maintainers ![](https://www.gravatar.com/avatar/998b1d9bf7b98bdb3a1d5eb58be362ac75401a0526b2c282ca2dcf0017ccbb8f?d=identicon)[Payvision-Ops](/maintainers/Payvision-Ops) --- Top Contributors [![toqueteos](https://avatars.githubusercontent.com/u/699969?v=4)](https://github.com/toqueteos "toqueteos (2 commits)")[![jjgallardo-payvision](https://avatars.githubusercontent.com/u/71698777?v=4)](https://github.com/jjgallardo-payvision "jjgallardo-payvision (1 commits)") --- Tags payvisionphpsdksdk-php ### Code Quality TestsPHPUnit Code StylePHP\_CodeSniffer ### Embed Badge ![Health badge](/badges/payvision-payvision-sdk-php/health.svg) ``` [![Health](https://phpackages.com/badges/payvision-payvision-sdk-php/health.svg)](https://phpackages.com/packages/payvision-payvision-sdk-php) ``` ### Alternatives [imdhemy/google-play-billing Google Play Billing 491.3M5](/packages/imdhemy-google-play-billing)[bitpay/sdk Complete version of the PHP library for the new cryptographically secure BitPay API 42337.5k4](/packages/bitpay-sdk)[paypayopa/php-sdk PHP SDK for PayPay Open Payment API 18279.6k3](/packages/paypayopa-php-sdk)[buckaroo/sdk Buckaroo payment SDK 12189.1k9](/packages/buckaroo-sdk)[yanlongli/app-store-server-api PHP client for App Store Server API. Manage your customers’ App Store transactions from your server.The App Store Server API is a REST API that you call from your server to request and provide information about your customers' in-app purchases. The App Store signs the transaction and subscription renewal information that this API returns using the JSON Web Signature (JWS) specification.App Store Server API is independent of the app’s installation status on the customer’s devices. The App Store server returns information based on the customer’s in-app purchase history regardless of whether the customer installed, removed, or reinstalled the app on their devices.To request transaction and subscription status information with this API, provide any original transaction identifier that belongs to the customer. The transaction history API responds with a complete list of transactions, 20 at a time, starting with the oldest first. The subscription status API returns the status for all of the customer’s subscriptions, organized by their subscription group identifier.Use the Send Consumption Information endpoint to send information to the App Store when customers request a refund for a consumable in-app purchase, after you receive the CONSUMPTION\_REQUEST App Store server notification. Your data helps inform refund decisions. 2532.0k](/packages/yanlongli-app-store-server-api)[contica/facturador-electronico-cr Un facturador de código libre para integrar facturación electrónica en Costa Rica a un proyecto PHP 2128.8k](/packages/contica-facturador-electronico-cr) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)