Payment Setup

Subscriby\Connector\Core\PaymentSetup. A gateway is connected one of two ways, and the core says which: by onboarding (the creator is sent to the gateway's own pages and comes back connected) or by the keys the gateway issued, typed into your surface and checked by the core as the dashboard's form checks them. The gateway list and the fields each needs come from the core, so a connector never names a gateway of its own. Every call but providers() takes the CreatorRef of the account talking and runs as that creator with the dashboard's own rules, and every refusal reaches you as PaymentSetupRefused with a stable reason.

providers()Copy Anchor Link

foreach ($this->payments->providers() as $gateway) {
    // $gateway->key (PaymentProviderKey), ->label, ->onboards, ->sandbox, ->fields
    foreach ($gateway->fields as $field) {
        // $field->name, ->label, ->choices (value => label when the field is a pick)
    }
}

Every gateway the core offers a project, each a PaymentProviderOption: the key a method names it by, the name the creator reads, whether it onboards (then fields is empty) or is configured from keys (then fields lists each PaymentFieldOption), and whether it also runs in a sandbox mode. The platform's own rails and the access-code pseudo-gateway are left out. No creator: the list is the core's own, so a surface may build a form from it before anyone is identified.

listForProject()Copy Anchor Link

foreach ($this->payments->listForProject($creator, $project) as $method) {
    // $method->provider, ->label, ->mode, ->active, ->linked, ->chargesEnabled, ->takesMoney()
}

The project's methods in storage order, each a PaymentMethodDetails: the gateway, its name, PaymentMode::Live or Test, whether checkouts offer it, whether the gateway's account is attached (false for an onboarding never finished) and whether the gateway reports it can charge (always true for a gateway configured from keys). takesMoney() is the three together.

configure()Copy Anchor Link

$method = $this->payments->configure($creator, $project, new PaymentMethodDraft(
    provider: PaymentProviderKey::gateway('paystack'),
    mode: PaymentMode::Test,
    config: ['apiKey' => $typed['apiKey'], 'apiSecret' => $typed['apiSecret']],
));

The keys are named as providers() lists them for the gateway and checked the way the dashboard's form checks them before anything is stored: every key the gateway needs, a pick among its choices, an email where the gateway wants one, and a prefixed key against the chosen mode (a live key on a sandbox method, or the reverse, is refused with the sentence that says so). The method is stored with its keys encrypted and switched on, and comes back as PaymentMethodDetails. A gateway that onboards is refused here (provider_unknown, with a sentence that names the other door), and a gateway the project already holds in that mode is already_configured.

onboardingUrl()Copy Anchor Link

$url = $this->payments->onboardingUrl($creator, $project, PaymentProviderKey::gateway('stripe'), PaymentMode::Live);

Where a gateway's own onboarding starts for the project, with the method row made or revived behind it; the address is the creator's alone and expires, so show it as a link they open themselves and never store it. A gateway configured from keys is refused here (provider_unknown, with a sentence that names the other door).

setActive() and delete()Copy Anchor Link

$off = $this->payments->setActive($creator, $method->id, false);
$this->payments->delete($creator, $method->id);

The switch the dashboard offers on a method, and its removal. An onboarding never finished cannot be switched on (invalid, in the core's words). Plans sold through a removed method stop offering it; nothing already paid changes.

RefusalsCopy Anchor Link