@jate/expo

Pour les applications Expo / React Native. Le parcours de paiement Jate côté mobile : un hook qui ouvre la page de paiement dans le navigateur intégré et lit ce que le retour apporte. Rien de plus, et c'est délibéré.

npx expo install @jate/expo expo-web-browser

Ce paquet n'est pas pour un site web. Il dépend de expo-web-browser, qui n'existe pas dans un bundle Vite, Next ou CRA. Sur le web, il n'y a rien à installer : votre backend rend paymentUrl, vous faites window.location.href = paymentUrl, et au retour vous interrogez votre backend. Voir la doctrine plus bas.

(Ce paquet s'appelait @jate/react en 0.1.0. Le nom laissait croire à un paquet React universel ; il est renommé, l'ancien est déprécié.)

Utilisation

import { useJateCheckout } from "@jate/expo";

function BoutonPayer() {
  const { open, opening } = useJateCheckout({
    returnUrl: "prayerlink://paiement/retour",
  });

  const payer = async () => {
    // Votre backend crée l'encaissement — POST /v1/checkouts avec @jate/sdk.
    // La clé secrète ne descend JAMAIS dans l'application.
    const { checkout } = await monBackend.creerEncaissement();

    await open(checkout.paymentUrl);

    // Au retour, DEMANDEZ au backend, qui relit l'encaissement :
    const verite = await monBackend.verifierPaiement(checkout.reference);
    if (verite === "paid") afficherSucces();
    else if (verite === "pending") afficherEnAttente(); // le webhook tranchera
    else proposerDeReessayer();
  };

  return <Button title="Payer" onPress={payer} disabled={opening} />;
}

Le retour est un confort, jamais une preuve

C'est la doctrine de Jate, et ce paquet s'y tient : l'issue rendue par open ne décide de rien. Le retour peut ne jamais arriver — un client qui ferme l'onglet après avoir payé —, arriver sans qu'un paiement ait eu lieu, ou être falsifié : c'est une URL, n'importe qui peut l'ouvrir.

Ce qui décide, c'est la relecture de l'encaissement par votre backend (GET /v1/checkouts/<id>, ou le webhook). Le hook vous rend de quoi savoir quoi relire, pas de quoi livrer.

C'est aussi pourquoi il n'existe pas d'équivalent pour le web : il n'y aurait rien à y mettre qu'une redirection et une lecture de paramètres d'URL — trois lignes qui ne valent pas une dépendance.

Ce que open rend

type JateCheckoutOutcome =
  | { status: "returned"; checkoutId: string | null; reference: string | null; url: string }
  | { status: "cancelled"; url: null }
  | { status: "error"; url: null; error: string };

• returned — le navigateur est revenu à returnUrl. checkoutId et reference sont lus dans jate_checkout et jate_reference.
• cancelled — fermeture, annulation, ou (Android) départ vers une autre application dont aucun retour ne viendra.
• error — le navigateur intégré n'a pas pu s'ouvrir.

Dans les trois cas, la suite est la même : demandez à votre backend.

returnUrl

Elle doit figurer parmi les adresses de retour autorisées de l'application, déclarées dans le tableau de bord — sinon Jate refuse la demande de paiement avant sa création.

C'est aussi le schéma de rappel d'ASWebAuthenticationSession sur iOS : sans elle, la session ne reconnaît pas le retour et l'issue retombe sur cancelled.

Aussi exporté

parseReturnParams(url) — lit jate_checkout et jate_reference d'une adresse de retour, utile si vous gérez le lien profond vous-même.

Voir aussi

• @jate/sdk — le client backend, celui qui crée les encaissements et vérifie les webhooks. Il embarque toute la documentation d'intégration, sous node_modules/@jate/sdk/docs/
• @jate/cli — tester sa clé, relayer les webhooks en local
• Référence complète de l'API

MIT