Download the PHP package zarbinco/laravel-sep-pcpos without Composer

Laravel SEP Central PC-POS

Laravel SEP Central PC-POS is an unofficial Laravel SDK intended to help Laravel applications integrate with SEP Central PC-POS services.

The package provides typed configuration and protocol data, OAuth access-token management, unique transaction identifier retrieval, receipt customization, single or shared purchases, and transaction inquiry and reconciliation.

Disclaimer

This package is unofficial and is not affiliated with or endorsed by Saman Kish or SEP. You must obtain valid service access and credentials directly from the payment provider.

Compatibility

• PHP 8.2+
• Laravel 12 or 13
• Laravel 13 requires PHP 8.3+

Installation

Install the package with Composer:

Laravel discovers the package service provider automatically.

Publishing configuration

Publish the configuration file with:

The published config/sep-pcpos.php file contains settings for service URLs, credentials, terminal identity, timeouts, TLS, token caching, and logging. Service URLs and sensitive values have no defaults and must be supplied for your own account and environment.

The identity URL is the complete OAuth token endpoint. The API URL is the base URL for Central PC-POS API communication. The scope must be supplied exactly as issued by the provider. Password-grant body credentials and optional HTTP Basic Authentication credentials are separate settings:

Access tokens are cached internally. When the identity service supplies a refresh token, the package uses it for renewal and safely falls back to the password grant only when the refresh grant is explicitly rejected.

Main API communication uses the configured SEP_PCPOS_API_URL, applies authentication internally, and normalizes the common SEP service response envelope. TLS verification remains enabled by default and can use a custom CA bundle. API requests are never retried automatically because repeating a financial request may be unsafe; recovery decisions belong to the operation using the transport.

Payment amounts passed to the SDK must already be expressed in the monetary unit required by the configured SEP service. The package does not silently convert toman and rial values.

Resolving the client

Dependency injection is the recommended Laravel style. The PcPosClient contract resolves the package's configured client:

The facade is a concise alternative and resolves the same PcPosClient service:

Ordinary purchase

Resolve the operation client, request an identifier, persist that identifier in your application, and then submit an ordinary single-account purchase with an explicit terminal:

Custom receipt

Every purchase mode accepts an optional receipt. Empty item labels and values are preserved when they are meaningful to the terminal layout:

Positional shared purchase

Supply amounts in the exact account order configured for the terminal. Zero placeholders are supported, and the SDK requires their exact sum to equal the total.

The amount list order must match the account order configured for the terminal in SEP's payment switch. The SDK cannot verify that remote configuration.

IBAN/account-identifier shared purchase

Provide one to ten already-calculated shares. The SDK validates exact totals and serializes Amount_Iban, but it does not calculate business percentages. Provider-side validation remains authoritative for account identifiers.

Bill payment

Bill payments require the provider-issued Bill ID and Pay ID. The SDK preserves them as strings and does not apply a guessed local checksum:

Purchase-ID payment

A single Purchase-ID payment fixes the protocol transaction type and account type internally:

Government/shared Purchase-ID payment

Government/shared Purchase-ID payments support one to ten ordered shares and validate that their exact sum equals TotalAmount. The first share requires a Purchase ID. A missing Purchase ID on a later share is serialized as 0, as specified by SEP.

SEP materials in circulation use more than one spelling for the government/shared Purchase-ID compound field. Configure protocol.purchase_id_share_wire_key in config/sep-pcpos.php, or SEP_PCPOS_PURCHASE_ID_SHARE_WIRE_KEY, to the field name required by your SEP deployment. The accepted values are:

• PurchaseId_Amont_Iban from the StartPayment parameter table
• PurchaseId_Amount_Iban from the government/shared Purchase-ID instruction text
• PurchaseID_Amount_Iban from the reviewed MerchantSample/reference payload

The SDK accepts no arbitrary field names and sends exactly one configured spelling. This setting is required only for government/shared Purchase-ID payments.

Operation observability

Lifecycle events and safe operation logging are opt-in and disabled by default. Enable them through SEP_PCPOS_EVENTS_ENABLED and SEP_PCPOS_LOGGING_ENABLED; SEP_PCPOS_LOG_CHANNEL optionally selects a Laravel logging channel.

The package dispatches PcPosOperationStarted, PcPosOperationSucceeded, and PcPosOperationFailed. Events contain only the logical operation and, for failures, a broad failure category. They intentionally exclude requests, results, exceptions, identifiers, amounts, account details, and other transaction data. Applications needing business-specific events should dispatch their own after receiving the typed SDK result.

Event listeners are operational observers, not authorization or payment-validation hooks. Listener and logger failures are isolated and never prevent an operation, replace its result or exception, or cause a retry. A listener may inspect $event->operation and a failure listener may also inspect $event->category.

When logging is enabled, fixed records contain only operation and, for failures, failure_category. The package does not automatically log financial request or response payloads and does not provide transaction audit logging.

Testing

Application tests can replace the public client with a strict, network-free fake. Configure the fake before resolving the application service under test:

Responses are consumed in FIFO order, requests are recorded in memory, and an unconfigured operation throws a testing configuration exception instead of fabricating success. The facade and a subsequently container-resolved PcPosClient use the same fake. Fake calls bypass transport, authentication, package events, and package logging.

There is no configuration or environment switch for fake payments. Tests must install the fake explicitly with SepPcPos::fake() before resolving application services that receive PcPosClient.

Network uncertainty can be tested without contacting SEP:

The configured TransportException is thrown unchanged. It still represents an uncertain remote outcome in application logic and must not be treated as permission to retry a payment.

An uncertain public reconciliation result can be configured with PcPosFixtures::uncertainInquiryResult(). The fake returns that configured result directly; it does not reproduce the real client's internal code-97 inquiry algorithm. All fixture defaults are synthetic and may be replaced with application-specific synthetic values.

Payment requests are never retried automatically. If a connection-level TransportException occurs after a payment request is dispatched, treat the result as uncertain. Do not submit another payment or generate a replacement identifier until the transaction has been reconciled.

Transaction inquiry and reconciliation

Use the same persisted identifier to inspect a transaction after an uncertain payment outcome. inquiry() performs exactly one non-destructive lookup:

reconcile() performs the same non-destructive lookup and makes exactly one additional inquiry only when SEP returns switch response code 97:

Normal inquiry explicitly sends CancelPendingRequest=false. SEP documentation states that omitting this field may expire a pending transaction, so the SDK never relies on the provider default.

Pending cancellation is a separate, explicit operation that requires the original identifier:

This operation sends CancelPendingRequest=true. Its result describes the transaction state and does not by itself guarantee cancellation. Pending cancellation is never automatically retried after a connection-level failure.

For safe uncertain-payment handling, receive and persist the identifier before starting payment. If StartPayment raises TransportException, do not submit another payment; inquire or reconcile using that same identifier. The host application remains responsible for persistence and for deciding when to reconcile.

Exception guide

• AuthenticationException covers identity-service and token-acquisition failures; its AuthenticationConfigurationException subtype identifies definite local authentication setup failures.
• TransportConfigurationException means the main API request was not sent because local request preparation or configuration failed.
• TransportException means main API communication was attempted and the remote outcome may be uncertain. Never treat it as proof that a payment failed or as permission to retry.
• RemoteValidationException is a structured HTTP 400 validation response and is also an ApiHttpException; other known non-success HTTP statuses use ApiHttpException.
• RemoteServiceException represents a type-valid service envelope that reports an operation-level service error.
• MalformedResponseException identifies an invalid common response envelope, while UnexpectedResponseDataException identifies invalid operation-specific data inside an otherwise valid envelope.

All package exceptions above share the PcPosException root. Application code should still handle TransportException separately because of its uncertain-outcome semantics.

Host application responsibilities

This SDK handles the protocol boundary, not the application's payment workflow. The consuming application remains responsible for persisting the identifier before StartPayment, storing its transaction and business records, preventing duplicate user submissions, deciding when to inquire or reconcile, mapping results to orders or invoices, enforcing authorization and permissions, maintaining business audit trails, and implementing UI, SMS, and allocation-percentage logic.

Security

Store credentials and other secrets in environment variables and never commit them to version control. Keep TLS verification enabled. If your environment requires a custom certificate authority, configure the CA bundle path instead of disabling certificate verification. Avoid printing, logging, or otherwise exposing resolved token values.

License

Laravel SEP Central PC-POS is open-source software licensed under the MIT License.