Achat intégré

Concept

Dans une application SaaS, l’achat intégré (In-App Purchase en anglais) fonctionne sur le même principe que dans les applications mobiles : il permet à un client d’augmenter sa consommation ou d’activer une fonctionnalité payante au moment exact où il en a besoin, sans quitter son parcours.

Plutôt que d’obliger l’utilisateur à se rendre dans une page « Mon abonnement », vous lui permettez d’agir directement depuis l’écran qu’il utilise déjà.
Résultat : une meilleure expérience utilisateur et une augmentation naturelle du revenu.

Exemples courants (à adapter à votre modèle de facturation) :

Un utilisateur effectue une action susceptible de générer un coût supplémentaire :

ajout d’un utilisateur
activation d’un module, d’une fonctionnalité, …

Avec un seul appel API à ProAbono, vous pouvez :

calculer le surcoût immédiat éventuel
connaître le nouveau prix de l’abonnement après modification

Ces informations sont affichées au client afin qu’il confirme explicitement son choix.
Cette étape de confirmation est obligatoire : elle sécurise la facturation et évite toute contestation ultérieure.

[caption id=“attachment_1019” align=“aligncenter” width=“465”]
Exemple d’affichage des informations de confirmation[/caption]

Si le client clique sur Confirmer, votre application valide simplement la modification via l’API ProAbono.
ProAbono se charge ensuite automatiquement de la facturation.

L’utilisateur n’a jamais besoin de quitter son contexte courant, ce qui fluidifie considérablement l’expérience.

Avantages complémentaires

Si l’utilisateur dispose d’un accès illimité ou si la modification n’entraîne aucun surcoût, l’API retourne un montant égal à 0.

Dans ce cas, il est généralement inutile de demander une confirmation.

Si la modification est payante, l’appel API permet également d’identifier les situations suivantes :

l’utilisateur n’a aucun moyen de paiement enregistré
l’utilisateur a trop d’impayés
l’utilisateur n’a pas accès à cette fonctionnalité

Selon le cas, vous pouvez afficher un message clair accompagné d’un lien pour ajouter un moyen de paiement ou changer d’offre.

Procédure d’implémentation

La mise en place d’un achat intégré avec ProAbono repose sur un processus simple en deux étapes.

1 – Calculer l’impact tarifaire

Le premier appel API, Quoting usage, permet de vérifier que la modification est autorisée et d’en calculer le coût éventuel.

Exemple :

POST /v1/Pricing/Usage
{
  "ReferenceCustomer": "cust-42",
  "ReferenceFeature": "users",
  "Increment": 2,
  "DateStamp": "2026-01-12T15:31:00.00Z",
  "NextTerm": true
}

Réponse de l’API :

{
  "IdBusiness": 42,
  "IdSegment": 69,
  "IdCustomer": 133700,
  "IdSubscription": 286407,
  "IdFeature": 6915,
  "ReferenceSegment": "demo-eur",
  "ReferenceCustomer": "cust-42",
  "ReferenceFeature": "users",
  "LabelLocalized": "Net à payer",
  "PricingLocalized": "8,97 €",
  "Currency": "EUR",
  "AmountSubtotal": 748,
  "AmountTotal": 897,
  "DatePeriodStart": "2026-01-02T15:33:00.00Z",
  "DatePeriodTerm": "2026-01-31T15:29:27.00Z",
  "Details": [...],
  "NextTerm": {
    "LabelLocalized": "Coût de l’abonnement après modification",
    "PricingLocalized": "220,78 €",
    "AmountSubtotal": 18399,
    "AmountTotal": 22078
  }
}

ProAbono fournit automatiquement les libellés et montants localisés (langue et devise du client), pour :

le coût immédiat à facturer
le prix de l’abonnement au prochain cycle de facturation

[caption id=“attachment_1019” align=“aligncenter” width=“465”]
Exemple d’affichage des données calculées[/caption]

2 – Confirmer la modification

Une fois la confirmation utilisateur obtenue, appelez l’API Update usage pour appliquer la modification.

Exemple :

POST /v1/Usage
{
  "ReferenceCustomer": "cust-42",
  "ReferenceFeature": "users",
  "Increment": 2,
  "DateStamp": "2026-01-12T15:31:00.00Z",
  "NextTerm": true
}

En cas de succès, l’API retourne l’usage mis à jour.

3 – Gérer les cas limites

L’API Quoting comme l’API Usage permettent également de détecter les situations où la modification est interdite.
Ces cas doivent être gérés afin de laisser le client autonome.

Dans ces situations, la réponse HTTP contient toujours :

un statut HTTP (403 ou 404)
un code d’erreur unique

Cas les plus fréquents :

Fonctionnalité inaccessible
HTTP 404 – Error.Api.Usage.NoneMatching
L’abonnement ne contient pas cette fonctionnalité.
Action recommandée : proposer un changement d’offre.

Aucun moyen de paiement
HTTP 403 – Error.Customer.PaymentSettings.Missing
La modification est payante, mais aucun moyen de paiement n’est enregistré.
Action recommandée : afficher un lien vers la page de saisie du moyen de paiement.

Trop d’impayés
HTTP 403 – Error.Customer.Billing.CappingReached
Le seuil d’impayés autorisé est dépassé.
Action recommandée : inviter le client à régulariser ses factures.