# Feature Request: Pass customer details to createSubscriptionCheckout

[Samuel-Fikre]

Problem

The method in the provider interface doesn't receive customer details (email, name), but many payment gateways require this information to initialize a transaction.

Currently, the method signature is:

createSubscriptionCheckout(data: {
  providerCustomerId: string;
  providerPriceId: string;
  successUrl: string;
  cancelUrl?: string;
  metadata?: Record<string, string>;
}): Promise<{ paymentUrl: string; providerCheckoutSessionId: string }>;

Why This Matters

Payment gateways often require customer details to:

• Display customer information on the checkout page
• Send payment confirmation emails
• Meet compliance and KYC requirements
• Prevent fraud by validating customer identity

Current Workarounds

Provider implementers are forced to use workarounds:

1. Store customer data in provider config (architecturally incorrect - config should be app-level, not per-customer)
2. Fetch from application database (wrong layer - provider adapter shouldn't know about app's DB)
3. Use placeholder values (causes API errors)
4. Make fields optional (may violate gateway requirements)

Proposed Solution

Add customer details to the createSubscriptionCheckout interface:

createSubscriptionCheckout(data: {
  providerCustomerId: string;
  providerPriceId: string;
  successUrl: string;
  cancelUrl?: string;
  metadata?: Record<string, string>;
  customer?: {
    email?: string;
    firstName?: string;
    lastName?: string;
  };
}): Promise<{ paymentUrl: string; providerCheckoutSessionId string }>;

This allows providers to pass customer information when the gateway requires it, while keeping it optional for gateways that don't need it.

Benefits

• Cleaner architecture - no need for workarounds
• Better support for gateway-specific requirements
• Consistent with how other provider methods handle customer data
• Backward compatible (fields are optional)

I'm happy to help I can implement this change and open a PR if you agree.

[linear]

PAY-200

[t3duk]

I may be missing something here, but, when a user signs up or before subscribing to a subscription, you create a customer:

await paykit.upsertCustomer({
  id: "user_123",
  email: "jane@example.com",
  name: "Jane Doe",
});

This will create a customer in your provider layer, Stripe, and when subscribing, i.e. creating a checkout session, the customer ID passed through will link information like the email and name to this ID which displays in the checkout.

The name and email get stored up in your provider, and you create a checkout session with your customer ID. Thus, the provider already knows the name and email.

So I don’t see a problem, unless I’ve missed something in what your suggesting.