@vaam-apps/vpay-sdk 0.11.0 → 0.12.1

package/dist/types.d.ts

@@ -9,8 +9,16 @@
  * `requires_payment_method` with {@link LastPaymentError} populated.
  */
 export type PaymentIntentStatus = "requires_payment_method" | "requires_action" | "processing" | "succeeded" | "canceled";
-/** Rail codes this SDK's `payment_method_types` values may hold. */
-export type PaymentMethodType = "mtn_momo" | "orange_money" | "notchpay";
+/**
+ * What this SDK's `payment_method_types` values may hold: a **rail code**
+ * (`mtn_momo`, `orange_money`, `notchpay`), meaning that rail pinned, or a
+ * **payment-method type** (`mtn_wallet`, `orange_wallet`, from 2026-10-23),
+ * meaning the payer's wallet network, with the server's router picking the
+ * rail at confirm (ADR-0029 D6, RFC-0008 as revised on 2026-10-23). A type
+ * needs a server with migration `0053`; an older one refuses it as an unknown
+ * rail. `ConfirmPaymentIntentParams` still names rail codes only.
+ */
+export type PaymentMethodType = "mtn_momo" | "orange_money" | "notchpay" | "mtn_wallet" | "orange_wallet";
 /** Redirect-rail next step, Stripe's own `next_action.redirect_to_url` shape. */
 export interface NextAction {
     type: "redirect_to_url";
@@ -1269,9 +1277,11 @@ export type ListCheckoutSessionsParams = {
  *
  * # The rail's code is the outer key, and that is the whole point
  *
- * On the wire this is `destination[<payment_method_type>][…]` — a
- * rail-agnostic container with a rail-specific interior, exactly as
+ * On the wire this is `destination[<rail code>][…]` — a rail-agnostic
+ * container with a rail-specific interior, much as
  * `payment_method_data[<payment_method_type>][…]` is on the confirm path. The
+ * outer key is always the code of the **rail** the charge was made on, never a
+ * payment-method type: the server refuses `destination[mtn_wallet]`. The
  * server strips the outer key and hands the interior to that rail's own
  * adapter, which is the only thing that knows what a payee looks like there.
  * An SDK that flattened this, or that wrote one rail's code into the body
@@ -1324,11 +1334,19 @@ export type RefundDestination = {
      * widening this one.
      */
     kind: "mobile_money";
-    /** The rail the charge was made on — its code becomes the outer key. */
+    /**
+     * The rail the charge was made on — its code becomes the outer key.
+     *
+     * A **rail code** (`"mtn_momo"`, `"orange_money"`, `"notchpay"`), never a
+     * payment-method type: `"mtn_wallet"` or `"orange_wallet"` here is refused by
+     * the server with a `400` naming `destination`. For an intent created with a
+     * type, the rail its charge was routed to is on no `/v1` object yet, so the
+     * caller has to know it another way.
+     */
     payment_method_type: PaymentMethodType;
     /**
      * The payee's number, **in international form, starting with `+`**. Sent as
-     * `destination[<payment_method_type>][msisdn]`.
+     * `destination[<rail code>][msisdn]`.
      */
     msisdn: string;
 };

package/dist/version.d.ts

@@ -9,4 +9,4 @@
  * releases. A hand-written constant has no such landmine — it just needs to
  * be bumped alongside `package.json`'s own `version` field.
  */
-export declare const SDK_VERSION = "0.11.0";
+export declare const SDK_VERSION = "0.12.1";

package/dist/version.js

@@ -9,4 +9,4 @@
  * releases. A hand-written constant has no such landmine — it just needs to
  * be bumped alongside `package.json`'s own `version` field.
  */
-export const SDK_VERSION = "0.11.0"; // x-release-please-version
+export const SDK_VERSION = "0.12.1"; // x-release-please-version

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@vaam-apps/vpay-sdk",
-  "version": "0.11.0",
+  "version": "0.12.1",
   "description": "The Node.js merchant SDK for vpay's /v1 API: OAuth2 private_key_jwt, payment intents, checkout sessions, refunds, events and webhook verification.",
   "license": "Apache-2.0",
   "publishConfig": {