@flopay/node 1.9.30 → 1.10.1

package/README.md

@@ -53,6 +53,19 @@ Type the setup request body with `CreateCardSetupSessionRequest` from `@flopay/s
 
 The context needs billing API v1.9.48 or later. Older billing APIs silently ignore it and set the card up exactly as before. Send values as you hold them: the billing API trims and uppercases `country` and `currency`, validates all three fields, and rejects an invalid value with a `400`. The context describes the transaction and never selects a gateway; the billing API alone decides which gateway verifies the card.
 
+### Saved payment methods
+
+Customers can keep saved payment methods of any type, not only cards, and the server-side flow is the same one as for saved cards. Merchant credentials stay on the merchant server: your server creates the setup session through its own authenticated billing API client, and no FloPay package sends the setup request. Type the body with `CreateCardSetupSessionRequest` from `@flopay/shared` exactly as for a card. Saving another method type needs no extra field, and the request carries no gateway hint, provider allow-list, or eligibility table. The billing API advertises which methods a setup session can save, and the SDK never decides which gateway or method is eligible.
+
+`@flopay/shared` types the mixed method types for list and delete:
+
+- `SavedPaymentMethodType` is `'card'`, `'wallet'`, `'paypal'`, or `'apm'`. `SAVED_PAYMENT_METHOD_TYPES` lists every value for exhaustive handling.
+- `SavedPaymentMethodDisplay` is one display-only saved method of any type, discriminated by `type`. Every variant has an `id` and a lifecycle `status`. A wallet, PayPal, or APM method always has a safe display `label`. A card has `brand`, `lastFour`, `expiryMonth`, and `expiryYear`, and its `label` is optional: when it is missing, build the display text from `brand` and `lastFour`, as the example below does. No variant carries a reusable credential, token, or card number. An existing `SavedCardDisplay` is a valid `SavedPaymentMethodDisplay` without a `type`, so card-only code keeps compiling.
+- `ListSavedPaymentMethodsQuery` is the list request's optional `type` filter. Leave it out to list every saved method, as card-only integrations do today.
+- `isSetupCheckoutSession` is `true` for a no-charge setup session (`checkoutMode: 'setup'`, zero amount, no products), whatever methods its `savableMethods` advertise. `isCardSetupCheckoutSession` is unchanged.
+
+Deleting a saved method works the same way for every type, with the same `PaymentMethodRemovalError` responses.
+
 ### Stripe checkout sessions and customers
 
 `checkout.sessions.retrieve()`, `expire()`, and `listLineItems()` call Stripe directly and normalize the result. `customers.create()`, `retrieve()`, and `update()` manage Stripe customers and return a normalized `Customer`.
@@ -133,6 +146,32 @@ export async function createCardSetupSession(post: AuthenticatedPost, userId: st
 }
 ```
 
+List saved payment methods of any type, optionally filtered by `type`, and label each one without branching on a gateway:
+
+```ts
+import type { ListSavedPaymentMethodsQuery, SavedPaymentMethodDisplay } from '@flopay/shared';
+
+// Your server's existing billing API client; it adds your merchant authentication.
+type AuthenticatedList = (query: ListSavedPaymentMethodsQuery) => Promise<SavedPaymentMethodDisplay[]>;
+
+export function describeSavedMethod(method: SavedPaymentMethodDisplay): string {
+  switch (method.type) {
+    case 'wallet':
+    case 'paypal':
+    case 'apm':
+      return method.label;
+    default:
+      // A card; card-only responses may omit `type`.
+      return method.label ?? `${method.brand} ending ${method.lastFour}`;
+  }
+}
+
+export async function listSavedWallets(list: AuthenticatedList): Promise<string[]> {
+  const wallets = await list({ type: 'wallet' });
+  return wallets.map(describeSavedMethod);
+}
+```
+
 Verify a Stripe webhook in a plain Node.js HTTP server:
 
 ```ts
@@ -223,6 +262,8 @@ The parameter and result types (`CreateSessionParams`, `CheckoutSessionResult`,
 
 `@flopay/node` has no card-setup method and holds no merchant credential. `CreateCardSetupSessionRequest` and `CardSetupFutureUse`, also exported by `@flopay/shared`, type the body your server sends to the authenticated `POST /v1/checkouts/sessions/setup` route with its own billing API client.
 
+Saved payment methods of any type are typed by `@flopay/shared` too: `SavedPaymentMethodDisplay`, `SavedPaymentMethodType`, `ListSavedPaymentMethodsQuery`, `AdvertisedSavableMethod`, and the `isSetupCheckoutSession` guard. `@flopay/node` adds no list or delete method for them.
+
 ## Errors
 
 SDK validation and billing API failures are `FloPayError`s from `@flopay/shared`; branch on `type` and `code`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flopay/node",
-  "version": "1.9.30",
+  "version": "1.10.1",
   "type": "module",
   "sideEffects": false,
   "publishConfig": {
@@ -27,7 +27,7 @@
   ],
   "dependencies": {
     "stripe": "^22.2.1",
-    "@flopay/shared": "1.9.30"
+    "@flopay/shared": "1.10.1"
   },
   "devDependencies": {
     "tsup": "^8.3.0",