Context
In v1, the card registration flow for subscriptions requires a pre-authorization step to store the card on the PaymentAccount:
PreRegisterPaymentMethod → creates SetupIntent
SetupIntent.confirm() → validates card + handles 3DS/SCA
- Pre-authorize (100 cents) with
registerCard=true → stores card in paymentAccount.cards
RegisterRecurringPayment → finds active card → passes PaymentMethod ID to Subscription.create()
handleRegisterLicenseSubscription → cancels the pre-authorization via ExternalEntityToPaymentEvent(CancelPreAuthorization(...))
This works but has drawbacks:
- Unnecessary hold on the customer's card (even if minimal at 100 cents)
- Extra round-trip to Stripe (pre-auth + cancel)
- Pre-auth amount excludes taxes (doesn't match subscription invoice
- Requires tracking on the License entity
Requirements (v2)
1. Save card from SetupIntent without pre-authorization
Add a new flow in softpayment that registers the card in directly from the confirmed SetupIntent's PaymentMethod, without requiring a pre-authorization or PayIn.
After , the PaymentMethod is already attached to the Stripe Customer. The new flow should:
- Retrieve the PaymentMethod from the confirmed SetupIntent
- Store it as an active card in
- Persist the appropriate event (e.g., )
2. Simplified subscription creation
With the card saved directly, the subscription flow becomes:
- → SetupIntent
- → 3DS/SCA + saves PaymentMethod on Customer
- New: RegisterCardFromSetupIntent → stores card in
- → finds card → creates Stripe subscription
No pre-authorization, no cancel, no .
3. 3DS/SCA handling
The SetupIntent confirmation already handles 3DS authentication. For the first subscription invoice, Stripe applies the recurring payment SCA exemption since the card was already authenticated during setup.
If the first invoice requires additional authentication (e.g., ), the portal should handle by presenting the 3DS challenge to the customer.
4. Impact on license-server
- Remove from License proto (or deprecate)
- Remove command and
- Remove logic from
- Remove handling from
Stripe documentation references
Current workaround (v1)
Minimal pre-authorization (100 cents) + automatic cancellation after subscription registration. Tracked via on the License entity.
EOF
)
Context
In v1, the card registration flow for subscriptions requires a pre-authorization step to store the card on the
PaymentAccount:PreRegisterPaymentMethod→ creates SetupIntentSetupIntent.confirm()→ validates card + handles 3DS/SCAregisterCard=true→ stores card inpaymentAccount.cardsRegisterRecurringPayment→ finds active card → passes PaymentMethod ID toSubscription.create()handleRegisterLicenseSubscription→ cancels the pre-authorization viaExternalEntityToPaymentEvent(CancelPreAuthorization(...))This works but has drawbacks:
Requirements (v2)
1. Save card from SetupIntent without pre-authorization
Add a new flow in softpayment that registers the card in directly from the confirmed SetupIntent's PaymentMethod, without requiring a pre-authorization or PayIn.
After , the PaymentMethod is already attached to the Stripe Customer. The new flow should:
2. Simplified subscription creation
With the card saved directly, the subscription flow becomes:
No pre-authorization, no cancel, no .
3. 3DS/SCA handling
The SetupIntent confirmation already handles 3DS authentication. For the first subscription invoice, Stripe applies the recurring payment SCA exemption since the card was already authenticated during setup.
If the first invoice requires additional authentication (e.g., ), the portal should handle by presenting the 3DS challenge to the customer.
4. Impact on license-server
Stripe documentation references
Current workaround (v1)
Minimal pre-authorization (100 cents) + automatic cancellation after subscription registration. Tracked via on the License entity.
EOF
)