Какова должна быть полезная нагрузка разработчика в биллинге in-app in-app v3 api?

Я использую биллинг в приложении в своем приложении, чтобы разблокировать премиальные функции. Платеж в приложении настроен правильно. Все кажется прекрасным, кроме «полезной нагрузки разработчика».

Пример приложения говорит

/* * TODO: verify that the developer payload of the purchase is correct. It will be * the same one that you sent when initiating the purchase. * * WARNING: Locally generating a random string when starting a purchase and * verifying it here might seem like a good approach, but this will fail in the * case where the user purchases an item on one device and then uses your app on * a different device, because on the other device you will not have access to the * random string you originally generated. * * So a good developer payload has these characteristics: * * 1. If two different users purchase an item, the payload is different between them, * so that one user's purchase can't be replayed to another user. * * 2. The payload must be such that you can verify it even when the app wasn't the * one who initiated the purchase flow (so that items purchased by the user on * one device work on other devices owned by the user). * * Using your own server to store and verify developer payloads across app * installations is recommended. */ 

Пример приложения использует пустую строку в качестве полезной нагрузки разработчика. Мой вопрос в том, какую строку использовать в качестве полезной нагрузки разработчика? Могу ли я использовать основной идентификатор электронной почты пользователя?

Пожалуйста, проверьте ниже ответ, он может решить вашу проблему:

Если вы используете расходный элемент (управляемый элемент), вы можете использовать произвольную сгенерированную строку

Шаг 1: до создания метода create:

  private static final char[] symbols = new char[36]; static { for (int idx = 0; idx < 10; ++idx) symbols[idx] = (char) ('0' + idx); for (int idx = 10; idx < 36; ++idx) symbols[idx] = (char) ('a' + idx - 10); } 

Шаг 2: установите класс RandomString и SessionIdentifierGenerator в своей деятельности

  public class RandomString { /* * static { for (int idx = 0; idx < 10; ++idx) symbols[idx] = (char) * ('0' + idx); for (int idx = 10; idx < 36; ++idx) symbols[idx] = * (char) ('a' + idx - 10); } */ private final Random random = new Random(); private final char[] buf; public RandomString(int length) { if (length < 1) throw new IllegalArgumentException("length < 1: " + length); buf = new char[length]; } public String nextString() { for (int idx = 0; idx < buf.length; ++idx) buf[idx] = symbols[random.nextInt(symbols.length)]; return new String(buf); } } public final class SessionIdentifierGenerator { private SecureRandom random = new SecureRandom(); public String nextSessionId() { return new BigInteger(130, random).toString(32); } } 

Шаг 3: передать полезную нагрузку в ваш запрос на покупку:

 RandomString randomString = new RandomString(36); System.out.println("RandomString>>>>" + randomString.nextString()); /* String payload = ""; */ // bGoa+V7g/yqDXvKRqq+JTFn4uQZbPiQJo4pf9RzJ String payload = randomString.nextString(); Log.e("Random generated Payload", ">>>>>" + payload); Log.d(TAG, "Launching purchase flow for infinite gas subscription."); mHelper.launchPurchaseFlow(this, SKU_GAS, IabHelper.ITEM_TYPE_INAPP, RC_REQUEST, mPurchaseFinishedListener, payload); 

Для получения дополнительной информации проверьте эту ссылку: токен, который идентифицирует пользователя

Надеюсь, он решит вашу проблему.

Для меня случайная строка не полезна, поскольку во-первых, она должна зависеть от пользователя, который ее купил, а не от устройства, которое было куплено. Во-вторых, это не потребляемый предмет, поэтому пустая строка может подойти, но не идеальна.

Поэтому мой путь к нему – создать зашифрованный хэш на основе ключа. Каждый раз, когда совершается покупка, он однозначно идентифицируется, поскольку хэш никогда не должен совпадать.

Так как ключ на всех устройствах одинаковый, его легко расшифровать и проверить правильность секретного сообщения.

Чтобы ключ оставался в секрете, я использовал различные функции манипуляции строками, чтобы замаскировать его, чтобы он не был сохранен видимым образом.

Пример анимации текста можно найти здесь: Android In App Billing: обеспечение открытого ключа приложения

String Base64EncodedPublicKey key = DecrementEachletter("Bl4kgle") + GetMiddleBit() + ReverseString("D349824");

Этот метод создания хэша на основе ключа позволяет полезной нагрузке быть уникальной и идентифицируемой, в то же время разумно защищенной. Это не пуленепробиваемый, но он уверен, что трудно взломать.