Client and resources.

Laravel PayRex exposes one PayrexClient singleton. Use the facade for concise calls or inject the client when explicit dependencies are preferable:

use ByRcsc\LaravelPayrex\Facades\Payrex;
use ByRcsc\LaravelPayrex\PayrexClient;

$fromFacade = Payrex::customers()->retrieve('cus_...');

final class CreatePayment
{
    public function __construct(
        private readonly PayrexClient $payrex,
    ) {}

    public function __invoke(): void
    {
        $customer = $this->payrex->customers()->retrieve('cus_...');
    }
}

Both forms resolve to the same client instance in the application container. Each resource object is also created once and reused by that client.

Resource catalog

Methods mirror the operations PayRex documents. For example, payments are created through payment intents rather than payments()->create(), and PayRex does not provide a retrieve route for a billing statement line item.

Named and typed parameters

Resource methods use named, typed arguments:

$customer = Payrex::customers()->create(
    name: 'Ada Lovelace',
    email: 'ada@example.com',
    metadata: ['account_id' => 'acct_1042'],
);

Enum objects and their equivalent string values are accepted where the method signature allows both. Enum values are converted to their API strings during form encoding.

Null arguments are omitted from the request. Passing null does not send an empty value and generally means “leave unchanged” on update methods.

The options escape hatch

Every resource operation has a trailing $options array. It is merged over the named parameters immediately before the request is encoded:

$intent = Payrex::paymentIntents()->create(
    amount: 10_000,
    paymentMethods: ['card'],
    options: [
        'new_api_field' => 'supported-before-the-next-release',
    ],
);

Use named parameters for modeled fields. Payment method options, for example, are a named paymentMethodOptions parameter on payment intents and checkout sessions; reach for options only for a PayRex field that is documented but not yet represented in the installed package version. Because options win during the merge, they can also override a named parameter.

Low-level requests

The client exposes get, post, put, and delete for confirmed PayRex routes that the package does not model yet:

$payload = Payrex::get('/new_resource/res_123', [
    'expand' => ['customer'],
]);

These methods return the decoded response as an array and still use package authentication, form encoding, timeouts, response metadata, typed exceptions, and safe GET retries.

Use pendingRequest() when you need the configured Laravel HTTP client itself:

$response = Payrex::pendingRequest()->get('/new_resource/res_123');

This is lower level: you are responsible for response decoding and error handling.

Response metadata

After any API response, inspect its status and headers:

$intent = Payrex::paymentIntents()->retrieve('pi_...');
$response = Payrex::lastResponse();

$response?->status;
$response?->headers;
$response?->successful();
$response?->hasHeader('Request-Id');
$response?->header('Request-Id');
$response?->headerValues('Set-Cookie');

lastResponse() is null before the first call and after a connection failure that produced no HTTP response. The client is a singleton, so the value always describes whichever call most recently completed in the current process.

Credentials and base URL

publicKey() returns the configured public key, and baseUrl() the API root the client is pointed at:

$publicKey = Payrex::publicKey(); // null when PAYREX_PUBLIC_KEY is unset
$baseUrl = Payrex::baseUrl();     // "https://api.payrexhq.com" by default

There is intentionally no secret-key accessor. The secret key should never leave the server, appear in logs, or enter a browser bundle.

What to read next

• Data objects and enums to read typed resource responses.
• Errors and retries to handle failures from any resource method.
• Testing to fake requests made by the shared client.