Procédure avancée : Achat intégré (2/2)

8 vues 0

< Article précédent : Achat intégré (1/2)

À l’instar des application mobiles, l’achat intégré dans un service par abonnement permet au client d’effectuer des ajustements sur son abonnement ou d’augmenter sa consommation en quelques clics. C’est un des meilleurs moyens d’accroître vos revenus en réduisant les interactions avec le client.

Implémentation

Étape 1 : Récupérer le coût de la modification

L’appel permettant de faire toutes ces vérifications et de calculer le tarif d’un éventuel surcoût est Compute pricing usage.
 

Exemple :

POST /v1/Pricing/Usage?referenceCustomer=cust_1&referenceFeature=team-members
 
{
  « Increment »: 2,
  « DateStamp »: « 2018-12-31T15:31:00.00Z »,
  « NextTerm »: true,
}

 
DateStamp est la date de la modification en temps universel (UTC). Dans la plupart des cas, utiliser l’heure (UTC) actuelle.
Résultat:
{
  "IdSegment": 7,
  "IdCustomer": 406146,
  "IdSubscription": 286407,
  "IdFeature": 6915,
  "ReferenceSegment": "dev",
  "ReferenceCustomer": "cust_1",
  "ReferenceFeature": "team-members",
  "LabelLocalized": "Net à payer",
  "PricingLocalized": "8.97 €",
  "Currency": "EUR",
  "AmountSubtotal": 748,
  "AmountTotal": 897,
  "DatePeriodStart": "2019-01-02T15:33:00.00Z",
  "DatePeriodTerm": "2019-01-31T15:29:27.00Z",
  "Details": [...],
  "NextTerm": {
    "IdSegment": 7,
    "IdCustomer": 406146,
    "IdSubscription": 286407,
    "ReferenceSegment": "dev",
    "ReferenceCustomer": "cust_1",
    "LabelLocalized": "Coût de l'abonnement après modification",
    "PricingLocalized": "220.78 €",
    "Currency": "EUR",
    "AmountSubtotal": 18399,
    "AmountTotal": 22078,
    "DatePeriodStart": "2019-01-31T15:29:27.00Z",
    "DatePeriodTerm": "2019-02-28T15:29:27.00Z",
    "Details": [...]
  }
}

ProAbono fourni automatiquement le libellé et le montant localisés dans la langue du client, pour le coût net à payer et le coût de l’abonnement après modification (dans le sous-object ‘NextTerm’).

Exemple d’affichage des données ci-dessus :

 

Étape 2 : Confirmation de la modification

L’appel permettant de confirmer une modification est Update usage. Le contenu (body) de l’appel est strictement identique à l’appel précédent.
 
Exemple :

POST /v1/Usage?referenceCustomer=cust_1&referenceFeature=team-members

 
En cas de succès, le résultat est l’usage après ajustement.
{
  "IdSegment": 7,
  "IdFeature": 6915,
  "IdCustomer": 406146,
  "IdSubscription": 286407,
  "ReferenceSegment": "dev",
  "ReferenceFeature": "team-members",
  "ReferenceCustomer": "cust_1",
  "TypeFeature": "Limitation",
  "QuantityIncluded": 3,
  "QuantityCurrent": 9,
  "DatePeriodStart": "2018-12-31T15:29:27.00Z",
  "DatePeriodEnd": "2019-01-31T15:29:27.00Z"
}

Cas supplémentaires (à gérer)

L’appel /v1/Pricing/Usage permet également des détecter plusieurs cas où la modification n’est pas autorisée. Il est souhaitable de gérer ces cas afin de permettre au client de faire le nécessaire en autonomie.

Lorsque ces cas se produisent, la réponse HTTP contient systématiquement :

  • Status HTTP : un statut HTTP 403 ou 404
  • Code : un code d’erreur unique

Voici les différents cas à gérer :

Caractéristique inacessible

HTTP 404 – Error.Api.Usage.NoneMatching

Le client n’a aucun abonnement contenant cette caractéristique. Il doit changer d’offre.

Solution : lui suggérer de changer d’offre.

Pas de moyen de paiement

Http 403 – Error.Customer.PaymentSettings.Missing

La modification est payante, mais le client n’a pas de moyen de paiement d’enregistré.

Solution : lui afficher le lien pour saisir ses moyens de paiement.

Trop d’impayés

Http 403 – Error.Customer.Billing.CappingReached

La modification est payante, mais le client a trop d’impayés (selon les seuils définis dans vos paramètres).

Solution : le client doit payer ses anciennes factures.

 

Cela vous a-t-il été utile ?

 
Articles liés