Getting startedRelease notesSDK

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.