# Apple technical support request
Buenos días

> Tenemos algunas dudas sobre la implementación de los pagos que tenemos integrados en la aplicación. Los productos consumibles que tenemos ahora mismo dados de alta son destacados que se aplican a anuncios previamente publicados (los usuarios pueden tener varios anuncios publicados en su cuenta) y validados en nuestros sistemas por los usuarios.

> *Salva: aquí he añadido algo de contexto en la traducción*

We are having a difficult time implementing in-app purchases in our application.
To add some context: we are a real estate platform where users can list their properties. The products we are selling in the app allow users to give more visibility to their properties on our listings, for a limited period of time (12h-24h), so they can potentially sale or rent their house faster.
What is important to notice is that if a user has two properties, he/she has to purchase two products, one for each property listed.
We are using consumable products for this.

> A la hora de crear el pago asociado al producto que ha elegido el usuario (Por ejemplo, destacado 48h) creamos un SKPayment con el identificador de dicho producto. Posteriormente lo añadimos a la cola de pagos SKPaymentQueue.default().add(payment). Finalmente utilizamos SKPaymentTransactionObserver para comprobar si las transacciones se han completado con éxito. Como este proceso es asíncrono, puede que se acumulen varias compras de diferencias anuncios.

When a user purchases a product, associated to a property, we create a SKPayment with the product identifier (for example a 24h property highlight). We add that payment to the queue with SKPaymentQueue.default().add(payment) and we wait for completion/error using SKPaymentTransactionObserver. This is an asynchronous process, and if the user purchases multiple products the observer will fire multiple times.

> El problema que tenemos es que cuando estas transacciones terminan, no sabemos enlazar las transacciones con los anuncios en los que se ha realizado el pago. Hemos revisado tanto las propiedades públicas del pago SKPayment como de la transacción SKPaymentTransaction para ver si podemos utilizar alguna de ellas como identificador único y al terminar la transacción asociarla con el pago original pero no hemos visto nada que podamos utilizar.

> *Salva: he añadido lo del applicationUsername, se puede quitar si no lo veis*

So when these transactions finish, either successfully or not, we have to match them with the corresponding property. But we can't find a way to do that. We have gone through all the SKPayment and SKPaymentTransaction public properties to see if we can add some kind of identifier (such us our propertyId) or if there is a payment ID we can rely on.
The only one that could be useful to us is applicationUsername (https://developer.apple.com/documentation/storekit/skpayment/1506116-applicationusername) but the docs are very clear as to when to use this:
"The applicationUsername property is not guaranteed to persist between when you add the payment transaction to the queue and when the queue updates the transaction. Do not attempt to use this property for purposes other than providing fraud detection."
So we ran out of options.

> Entendemos que en otro tipo de aplicaciones, como por ejemplo un juego, el identificador del producto que está dado de alta en iTunes identifica unívocamente lo que hay que activar al usuario, pero en este caso un mismo identificador de producto puede ser comprado y aplicado a varios anuncios (por ejemplo, se puede comprar el destacado 48h para varios de los anuncios que tiene publicados).

We understand that for other applications, like games, the product identifier is all that's needed to activate the service. There is no extra information required, but our use case is different: a user can purchase the same product (24h highlight) for multiple properties, and we need to know which ones.

> ¿Cómo podríamos identificar en el método updatedTransactions relativo al SKPaymentTransactionObserver sobre qué anuncio debemos aplicar el destacado?

When the SKPaymentTransactionObserver.updatedTransactions method is called, how can we know what property is associated to that payment?

> ¿Sería razonable implementar nuestra propia pasarela de pago en vez de integrarnos con los in app purchases? Parece que el API asociado a los in app purchases nos está dando pistas que estamos utilizando una herramienta que no se adapta a nuestras necesidades y ya que nos desbloqueamos ninguna funcionalidad extra en la aplicación nos parece razonable preguntaros si esta opción es viable. Por ejemplo otras aplicaciones como “Vinted” utilizan esta solución vs in app purchases

> *Salva: mencionamos que tenemos incis de pagos por este problema? *

Are we missing anything? We are starting to think that the in-app purchases API is not the right tool for us as we are not unlocking extra content in the app.
Should we use a payment gateway instead of in-app purchases for this use case? We see apps like "Vinted" offer this same product without using in-app purchases.

> Gracias!