Vendre sans le Store Kit depuis une application

muqaddarmuqaddar Administrateur
04:17 modifié dans Vos applications #1
Salut,

J'ai un prospect qui souhaite réaliser des ventes depuis la (future) application iPhone sans passer par Apple et le StoreKit.
Il y aurait donc des aller/retours sur le serveur qui vend avec un compte client (comme un site web).

Evidemment c'est faisable, mais je me pose une question concernant la sécurité au moment de la phase d'achat. Si sur un site Internet on passe en mode https sur la page d'une API bancaire quand on saisit ses infos de carte bancaire, qu'en-est-il dans une application ?

Autrement dit, le moyen le plus sûr est-il de de créer une WebView https uniquement au moment de payer ? (et faire tout le reste avec NSURLConnection).



Réponses

  • DrakenDraken Membre
    04:17 modifié #2
    Apple n'interdit-elle pas ce genre de pratiques ?

  • muqaddarmuqaddar Administrateur
    04:17 modifié #3
    dans 1289912585:

    Apple n'interdit-elle pas ce genre de pratiques ?


    Alors comment font les applis type MacWay sorties hier uniquement faites pour vendre ?
  • DrakenDraken Membre
    novembre 2010 modifié #4
    C'est peut être autorisé parce qu'il s'agit d'une boutique ayant pignon sur rue, vendant des produits physiques ?

    En tout cas, Apple refuse de valider des systèmes d'abonnement à  des revues en ligne ne passant pas par l'In-App et les 30% de commission. Le "blocage" ne concerne peut être que la vente de produits dématérialisés ?


  • 04:17 modifié #5
    Ayant bossé sur LeclercDrive pour iPhone (je sais, l'UI est horrible.. berk), Apple autorise effectivement la ventes de produits physiques via n'importe quel type de paiement. Mais cela se fait via une page web sécurisée adaptée à  l'écran de l'iPhone.
  • muqaddarmuqaddar Administrateur
    04:17 modifié #6
    dans 1289914173:

    Ayant bossé sur LeclercDrive pour iPhone (je sais, l'UI est horrible.. berk), Apple autorise effectivement la ventes de produits physiques via n'importe quel type de paiement. Mais cela se fait via une page web sécurisée adaptée à  l'écran de l'iPhone.


    Et donc pas de produits dématérialisés type PDF ?
  • 04:17 modifié #7
    dans 1289914370:



    Et donc pas de produits dématérialisés type PDF ?


    J'ai presque envie de dire "tente". Mais préviens le client que c'est un risque de perte de temps. Qui lui coûtera des sous :D
  • DrakenDraken Membre
    04:17 modifié #8
    Oui, mais en prévoyant la possibilité d'un rejet, nécessitant une nouvelle version passant par l'In-App, avec les 30% de commissions Apple. Cela n'est pas sans conséquence sur le modèle économique de ton client.

  • zoczoc Membre
    novembre 2010 modifié #9
    Extrait des "Review Guidelines" (que je te conseille d'aller consulter):


    11. Purchasing and currencies

    11.1
    Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
    11.2
    Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected




    Et sinon, pour répondre à  ta question initiale, il suffit que le WebService chargé du paiement fonctionne en HTTPS uniquement au lieu de HTTP pour avoir une sécurité équivalente à  un site WEB tout en utilisant un NSURLConnection.
  • muqaddarmuqaddar Administrateur
    04:17 modifié #10
    dans 1289923283:

    Extrait des "Review Guidelines" (que je te conseille d'aller consulter):

    11. Purchasing and currencies

    11.1
    Apps that unlock or enable additional features or functionality with mechanisms other than the App Store will be rejected
    11.2
    Apps utilizing a system other than the In App Purchase API (IAP) to purchase content, functionality, or services in an app will be rejected


    Ah bein merci Zoc.

    Il est où ce Review Guidelines que j'ai cherché partout sur l'ADC ? (et même dans iTunes Connect)
    Que j'envoie le lien au client...
  • muqaddarmuqaddar Administrateur
    04:17 modifié #11
    dans 1289921770:

    Oui, mais en prévoyant la possibilité d'un rejet, nécessitant une nouvelle version passant par l'In-App, avec les 30% de commissions Apple. Cela n'est pas sans conséquence sur le modèle économique de ton client.


    Il voulait passer par l'AppStore au départ pour l'achat de contenu supplémentaire... mais comme il veut vendre des modules depuis son site Internet également, il pensait faire un système "générique" pour le web et les apps.
  • muqaddarmuqaddar Administrateur
    04:17 modifié #12
    Trouvé. Va falloir faire un copier/coller car il n'est pas accessible aux personnes tierces. ???

    http://developer.apple.com/appstore/resources/approval/guidelines.html
  • muqaddarmuqaddar Administrateur
    novembre 2010 modifié #13
    Bon j'ai contacté mon prospect.

    En fait, il s'agirait plutôt de télécharger des modules déjà  achetés sur son site (en se connectant avec son compte client) mais pas de les acheter depuis l'application, ce qui, je pense change tout ?

    Par exemple :

    - L'application est livrée avec 50 modules démos.
    - Si l'utilisateur a un compte sur le serveur du client, il se connecte avec et peut avoir la liste des modules qu'il a déjà  achetés sur le site.
    - Il les re-télécharge dans l'application pour profiter de certaines fonctionnalités de l'iPhone ou l'iPad liées à  ces fichiers.

    S'il n'a pas de compte client, il n'utilise que ce qui est livré en standard dans l'application.

    Votre avis ? Pour moi, ça ressemble à  une connexion client/serveur comme il y a dans plein d'applications pour profiter de fonctions supplémentaires...et pis c'est tout.

    A la limite, Apple ne sait même pas si ces modules ont été payés ou pas sur le site du client il y a X jours...

  • DrakenDraken Membre
    novembre 2010 modifié #14
    Cela devrait passer. Certains éditeurs de revues utilisent un système similaire. Les abonnés à  la revue papier peuvent recevoir gratuitement la version online, en donnant leurs identifiants clients, tandis que les non-abonnés doivent faire un achat en In-App.



  • muqaddarmuqaddar Administrateur
    04:17 modifié #15
    Merci de ta réponse Draken. De toute façon, j'ai prévenu le client... :)
Connectez-vous ou Inscrivez-vous pour répondre.