> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mangopay.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mangopay.com/_mcp/server.

# Java SDK - 2.64.0

May 21, 2026

## Added

### Recurring Apple Pay and Google Pay pay-ins

Support for the new `POST /payins/payment-methods/applepay/recurring` and `POST /payins/payment-methods/googlepay/recurring` endpoints, plus a unified entry point that follows the same shape as non-recurring pay-ins:

* New `RecurringPayInRegistration` entity (with all common registration fields: `Status`, `ResultCode`, `ResultMessage`, `CurrentState`, `RecurringType`, `TotalAmount`, `CycleNumber`, `AuthorId`, `CardId`, `CreditedUserId`, `CreditedWalletId`, `Billing`, `Shipping`, `EndDate`, `Frequency`, `FixedNextAmount`, `FractionedPayment`, `FreeCycles`, `FirstTransactionDebitedFunds`, `FirstTransactionFees`, `NextTransactionDebitedFunds`, `NextTransactionFees`, `Migration`, `ProfilingAttemptReference`, `PaymentType`, `CardInfo`) and two subtypes: `RecurringApplePayPayInRegistration` (carries `PaymentData` object) and `RecurringGooglePayPayInRegistration` (carries `PaymentData` string).
* `RecurringPayInRegistrationPaymentType` enum extended with `APPLEPAY` and `GOOGLEPAY`.
* New `PayInApi` methods:
  * `createRecurringPayInRegistration(...)`, `createRecurringApplePayPayInRegistration(...)`, `createRecurringGooglePayPayInRegistration(...)`
  * `getRecurringPayInRegistration(...)`
  * `updateRecurringPayInRegistration(...)`, `updateRecurringApplePayPayInRegistration(...)`, `updateRecurringGooglePayPayInRegistration(...)`
  * `createRecurringPayIn(String idempotencyKey, RecurringPayIn recurringPayIn)` — a single entry point covering CIT/MIT for card, PayPal, Apple Pay and Google Pay, mirroring the non-recurring `PayIn` pattern.
* New endpoint mappings in `ApiBase`: `payins_recurring_card-direct_create`, `payins_recurring_paypal-web_create`, `payins_recurring_applepay-direct_create`, `payins_recurring_googlepay-direct_create`.
* New `RecurringPayInSerializer` (registered on `RecurringPayIn`) that adds `RecurringPayinRegistrationId` to the serialized body; `RecurringPayIn.setRecurringPayinRegistrationId(...)` setter added.
* `IdempotencyApiImpl` mappings added for the four new recurring endpoints so replayed idempotent calls return a typed `RecurringPayIn`.
* `RecurringPayInDeserializer` extended to deserialize Apple Pay and Google Pay payment details, plus the missing card fields (`Shipping`, `BrowserInfo`, `IpAddress`, `Bic`, `BankName`, `PreferredCardNetwork`), the PayPal `DataCollectionId`, and the direct execution detail `RecurringPayinRegistrationId`.

### Extra fields on existing card pay-in responses

`PayInDeserializer` now also deserializes `Shipping`, `BrowserInfo` and `IpAddress` on `PayInPaymentDetailsCard`, and `Shipping` on `PayInPaymentDetailsPreAuthorized`.

### PayPal deposit preauthorizations

Support for the `POST /deposit-preauthorizations/payment-methods/paypal` endpoint:

* New `PayPalDepositPreauthorization` entity extending `Deposit` with PayPal-specific fields (`PaypalPayerID`, `PaypalOrderID`, buyer details, `CancelURL`, `ReturnURL`, `RedirectURL`, `ShippingPreference`, `Trackings`, `LineItems`, `Reference`, `DataCollectionId`).
* New `DepositApi.createPayPalPreauthorization(...)` method, routed through the new `deposits_paypal_create` endpoint mapping in `ApiBase`.
* `IdempotencyApiImpl` mapping added for `deposits_paypal_create` so replayed idempotent calls return a typed `PayPalDepositPreauthorization`.

### Local Virtual Account properties for DK, AU, LI

Added properties to support `LocalAccount` details on Virtual Accounts:

* For DK, `BankCode` (4-digit bank code)
* For AU, `BSBCode` (6-digit Bank State Branch code)
* For LI, `BCNumber` (5-digit bank clearing number)

## Deprecated

### Legacy recurring pay-in methods on `PayInApi`

The following methods are now `@Deprecated`. They continue to work but will be removed in a future major version release. You should migrate to the new methods above:

* `createRecurringPayment(...)` → use `createRecurringPayInRegistration` / `createRecurringApplePayPayInRegistration` / `createRecurringGooglePayPayInRegistration`
* `getRecurringPayment(...)` → use `getRecurringPayInRegistration`
* `updateRecurringPayment(...)` → use `updateRecurringPayInRegistration` / `updateRecurringApplePayPayInRegistration` / `updateRecurringGooglePayPayInRegistration`
* `createRecurringPayInCIT(...)`, `createRecurringPayInMIT(...)`, `createRecurringPayPalPayInCIT(...)`, `createRecurringPayPalPayInMIT(...)` → use the unified `createRecurringPayIn(...)`

## Fixed

### Serialization and deserialization bugs surfaced while wiring recurring pay-ins

* `PayInSerializer` for Google Pay V2: the body was previously emitting `RedirectURL` twice (the second time with the value of `ReturnUrl`). The second entry is now correctly serialized as `ReturnURL`.
* `PayInDeserializer` and `RecurringPayInDeserializer` for PayPal: the `PaypalPayerID` field on the response was being routed into `setPaypalOrderID(...)`, overwriting the order ID with the payer ID. It is now correctly set via `setPaypalPayerId(...)`.
* `CurrentState`: the `@SerializedName` for `payinsLinked` was `"PayinsLinked "` (trailing space), so the field was never populated. Corrected to `"PayinsLinked"`.

## Changed

### `DepositDeserializer` returns the correct deposit subtype

`DepositApiImpl` now registers a `DepositDeserializer` on the shared `GsonBuilder` (via the new `DepositApiImpl(MangoPayApi, GsonBuilder)` constructor wired up in `MangoPayApi`). The deserializer inspects the `PaymentType` field on the response and instantiates `PayPalDepositPreauthorization` when it equals `PAYPAL`, falling back to the base `Deposit` otherwise.

As a result, `get(...)`, `update(...)`, `cancel(...)`, `getAllForUser(...)` and `getAllForCard(...)` on `DepositApi` now transparently return the appropriate subtype for every supported deposit payment method — single-resource calls yield the right subtype directly, and the list endpoints can return a mixed `List<Deposit>` whose entries are each instantiated as `PayPalDepositPreauthorization` (or any future subtype) according to their `PaymentType`. Callers can cast individual elements to access method-specific fields.