feat: add Android SDK 7.1014.0 and REST API 2.30.0 versions

android/androidreleasenotes.md

@@ -34,6 +34,22 @@ dependencies {
 
 Added support for Address Verification Service (AVS) checks on MoTo transactions. You can now pass the cardholder's billing details via [`MoToOptions.billing`](androidobjects.md#moto-options), or set [`MoToOptions.enableAvsFields`](androidobjects.md#moto-options) to have the MoTo Dialog collect them from the cardholder instead. See the [Billing](androidobjects.md#billing) object for details. The result of the check performed by the acquirer is returned on [`TransactionResult.addressVerification`](androidobjects.md#25), see the [Address Verification](androidobjects.md#address-verification) object.
 
+## 7.1013.0
+
+**New Features**
+
+- Duplicate-Check support is now available for MoTo Sale operations, preventing double-charges when a sale is retried after a network or connectivity issue.
+- Deferred Tokenization is now supported in the Android SDK, allowing integrators to tokenize a card used in a previous sale, refund, pre-authorization capture, MoTo sale or MoTo refund at a later point using the transaction's GUID. See the [REST API 2.26.0 Deferred Tokenization](pathname:///restapi/restreleasenotes) endpoint for the corresponding gateway operation.
+
+**Improvements**
+
+- Contactless (NFC) reading performance has been improved: the NFC reader is no longer reinitialised on every polling cycle, resulting in faster and more reliable tap detection, including quick taps.
+- MoTo Sale transactions that return an UNDEFINED result can now recover the approved result via the Get Transaction Status service. Previously, MoTo Sale did not include a `transactionReference`, making status recovery impossible.
+
+**Bug fixes**
+
+- Fixed: Card entry type now correctly reports `CHIPFAILMAGSTRIPE` instead of `TOKENIZATION` when a chip card falls back to magnetic stripe.
+
 ## 7.1012.3
 **Features**
 

android_versioned_docs/version-Android SDK 7.1014.0/androidapioverview.md

@@ -0,0 +1,22 @@
+---
+sidebar_position: 4
+id: androidapioverview
+---
+
+# Trigger Amounts 
+
+Your test payments are sent against a test server on the Handpoint side which simulates the behavior of an acquiring bank. Funds are not moved and sensitive data from the card is fully encrypted. You can use trigger amounts to generate some specific responses from our servers:
+
+**Sale amounts**
+
+| Amount      | Behaviour |
+| ----------- | ----------- |
+| 37.79      | Issuer response code = 01 (Refer to issuer)       |
+| 37.84      | Issuer response code = 05 (Not authorized)        |
+| 37.93      | Issuer response code = 04 (Pick up card)       |
+| 37.57      | Request is partially approved      |
+| 37.68      | Request timeout       |
+
+:::tip
+Supporting partial approval is **mandatory** for the US market. Partial authorization occurs when a payment card authorization is attempted for a transaction and there are not enough funds available in the account to cover the full amount. The issuer returns an authorization for the amount available in the account, leaving you to obtain an additional form of payment from the customer for the balance.
+:::