SDK Objective-c

Ciblez l'URL de base de l'API la plus à jour

Notre SDK natif vous aide à communiquer avec l'API Client. Il offre :

• Des encapsulations pratiques pour les réponses de l'API.
• La gestion de tous les détails concernant le chiffrement des informations de paiement.
• La mise en cache des logos de moyens de paiement et des images pour offrir des informations supplémentaires sur les moyens de paiement.
• Un formatage ergonomique des données de paiement telles que les numéros de carte et les dates d'expiration.
• La validation de la saisie.
• Des vérifications pour déterminer à quel émetteur un numéro de carte est associé.

Notre application d'exemple simule l'interface utilisateur pour tout le flux de paiement basé sur l'interaction entre l'application et notre plateforme. Trouvez le code source du SDK et de l'application d'exemple sur GitHub, y compris les instructions d'installation.

Une fois que vous êtes prêt, lisez les chapitres suivants sur la préparation et l'utilisation du SDK.

Pour créer des paiements, vous devez d'abord intégrer le SDK à votre projet. Toutes les versions du SDK sont disponibles publiquement dans notre repository. Pour simplifier leur utilisation, nous avons préparé un package ci-dessous pour une intégration rapide.

Le SDK est disponible via des gestionnaires de paquets : CocoaPods ou Carthage.

CocoaPods

Vous pouvez ajouter le SDK comme un pod à votre projet en ajoutant le snippet de code suivant à votre Podfile :

$ pod 'OnlinePaymentsSDK'

Ensuite, exécutez la commande suivante :

$ pod install

Carthage

Vous pouvez ajouter le SDK avec Carthage en ajoutant le snippet de code suivant à votre Cartfile :

$ github "wl-online-payments-direct/sdk-client-objc"

Ensuite, exécutez la commande suivante :

$ carthage update

Après l'intégration réussie du SDK à votre projet, vous pouvez passer au processus d'intégration avec le système de paiement complet. Le processus de paiement complet comprend les étapes suivantes :

1. Initialisation des objets Session et PaymentContext
2. Réception des méthodes de paiement possibles
3. Réception et affichage des détails des méthodes de paiement
4. Validation des données fournies
5. Chiffrement et transfert des données de paiement
6. Finalisation de la transaction

1. Initialiser les objets OPSession et OPPaymentContext

Tout d'abord, vous devez créer un OPSession permettant la communication entre l'API Serveur et le client. Votre application doit avoir son propre serveur, agissant comme un intermédiaire entre notre API Client et Serveur.

Étant donné que le client initie le paiement dans son application, l'application Client demande à l'application Serveur de créer une Session. Lorsqu'une application Serveur reçoit une demande, elle peut créer une Session via Créer une Session à partir du SDK Serveur.

Après avoir configuré et connecté votre application à l'API Serveur, vous recevez une réponse contenant des informations sur la Session créée. Une réponse typique ressemble à ceci :

{
    "assetUrl": "https://assets.test.cdn.v-psp.com/s2s/515c2c0bd13d5dd4bd42",
    "clientApiUrl": "https://payment.preprod.direct.worldline-solutions.com/",
    "clientSessionId": "68a4b0b183a34016b4b694b97938f75b",
    "customerId": "cf7d7aafd42e4a1cb9e4b0624a5041b1",
    "invalidTokens": []
}

Transmettez maintenant assetUrl, clientApiUrl, clientSessionId et customerId à l'application Client. Une fois que l'application reçoit une réponse de l'application Serveur avec les informations concernant la Session, créez un objet local Session côté application Client.

Ensuite, créez un objet OPPaymentContext. Il contient des informations sur le mode de paiement, la devise, le pays, le montant, etc. Vous utiliserez les objets OPPaymentContext et OPSession tout au long du processus de paiement.

2. Recevoir les méthodes de paiement possibles

La prochaine étape consiste à obtenir et à afficher les options de paiement possibles. Pour ce faire, utilisez les objets OPSession et OPPaymentContext préalablement créés pour invoquer la méthode GetBasicPaymentItems, qui envoie GetPaymentProducts à notre API Serveur.

Jetez un œil à cet exemple de code montrant comment initialiser une instance de la classe OPPaymentContext et l'utiliser pour obtenir la liste des OPBasicPaymentItems avec l'objet OPSession.

NSInteger amountValue = 100;
NSString *countryCode = @"NL";
NSString *currencyCode = @"EUR";
BOOL isRecurring = NO;

OPPaymentAmountOfMoney *amountOfMoney = [[OPPaymentAmountOfMoney alloc] initWithTotalAmount:amountValue currencyCode:currencyCode];

OPPaymentContext *context = [[OPPaymentContext alloc] initWithAmountOfMoney:amountOfMoney isRecurring:isRecurring countryCode:countryCode];

[session paymentItemsForContext:context groupPaymentProducts: NO success:^(OPPaymentItems *paymentItems) {
    // Permettre au client de sélectionner un élément de paiement et un compte optionnel
    // à partir de la liste des éléments de paiement
    // représentés par paymentItems.
} failure:^(NSError *error) {
    // Indique qu'une erreur est survenue.
}];

3. Recevoir et afficher les détails des méthodes de paiement

Les éléments de paiement sont des instances de OPBasicPaymentProduct. Votre application peut utiliser ces éléments pour créer un écran qui les liste tous. Utilisez notre application d'exemple pratique comme base pour votre propre implémentation.

Pour certains moyens de paiement, les clients peuvent indiquer qu'ils souhaitent que notre plateforme conserve leurs identifiants pour les paiements Card On File. Nous appelons ces données stockées un compte enregistré ou token. Vous pouvez réutiliser ce compte enregistré / token pour des paiements ultérieurs si vos clients choisissent la même méthode de paiement.

La liste des moyens de paiement disponibles que le SDK reçoit de l'API Client contient également les comptes enregistrés pour chaque moyen de paiement. Votre application peut présenter cette liste à l'utilisateur.

En fonction de la méthode choisie par le client, envisagez des cas de flux de données différents :

Si l'utilisateur a choisi une forme de paiement native, vous devez utiliser le SDK du fournisseur de paiement et gérer la réponse uniquement à la dernière étape pour informer l'utilisateur du statut du paiement. Lisez-en plus sur les paiements natifs dans le chapitre dédié.

Pour les paiements avec un fournisseur de paiement tiers, vous recevez des données avec l'adresse de redirection dans les propriétés de paiement. Redirigez vos clients dans leur navigateur vers le portail de paiement tiers pour continuer le processus de paiement. Après le paiement réussi, votre application doit gérer la redirection vers l'application Client.

Le processus de paiement standard est un paiement par carte. Une fois que vos clients ont sélectionné un élément de paiement ou un account on file (compte enregistré), le SDK Client peut demander les informations nécessaires que vos clients doivent fournir pour le paiement.

Un objet représentant la méthode de paiement OPBasicPaymentItem fournit une liste des champs que votre application doit afficher, y compris des indices et des règles de validation. Si vos clients sélectionnent un account on file (compte enregistré), les informations déjà disponibles peuvent être pré-remplies dans les champs de saisie au lieu de les demander à vos clients. Les données pré-remplies au nom du client sont conformes aux réglementations applicables. Selon le cas d'utilisation individuel, vos clients pourraient encore avoir à fournir certaines données (par exemple, le CVC).

4. Valider les données fournies

À présent, votre application doit valider les données saisies par vos clients dans l'interface de votre application. Pour cela, utilisez le composant de validation des données. L'interface de saisie des données doit être entièrement transparente et compréhensible pour vos clients. Nous recommandons d'utiliser les OPToolTips, qui disposent de champs individuels ou affichent des erreurs de validation appropriées.

5. Chiffrer et transférer les données de paiement

Sur la base des données collectées, vous devez créer une instance de OPPaymentRequest. Cette classe possède une propriété tokenize qui indique si l'application doit stocker les identifiants du client pour des paiements Card On File.

Utilisez l'exemple de code suivant pour les demandes de paiement sans comptes enregistrés :

OPPaymentRequest *paymentRequest = [[OPPaymentRequest alloc] init];
paymentRequest.paymentProduct = paymentProduct;
paymentRequest.accountOnFile = nil;
paymentRequest.tokenize = NO;

Alternativement, adaptez l'exemple de code en fournissant à la fois le compte enregistré et le moyen de paiement correspondant :

paymentRequest.accountOnFile = accountOnFile

Une fois que vous configurez une requête de paiement, fournissez les valeurs pour les champs du moyen de paiement. Utilisez les identifiants des champs, tels que "cardNumber" et "cvv" pour définir les valeurs des champs pour la requête de paiement :

[paymentRequest setValue:@"1234567890" forField:@"cardNumber"];
[paymentRequest setValue:@"123" forField:@"cvv"];

Vous pouvez maintenant valider la requête de paiement. Par conséquent, une liste d'erreurs est disponible. Pour toute erreur de validation, vous devez fournir un retour d'information au client. Pour plus d'informations, lisez le chapitre dédié.

[self.paymentRequest validate];
if (self.paymentRequest.errors.count == 0) {
    // La requête de paiement est valide et peut être chiffrée et envoyée à
    // notre plateforme via le serveur du commerçant.
} else {
    // Informez le client que certains champs contiennent des données invalides.
}

Après la validation de la PaymentRequest, chiffrez la requête et envoyez-la à votre application serveur. Consultez l'exemple de code montrant comment utiliser une instance de OPSession pour chiffrer une requête :

[session preparePaymentRequest:paymentRequest
    success:^(OPPreparedPaymentRequest *preparedPaymentRequest) {
        // Soumettez les informations contenues dans la
        // requête de paiement chiffrée représentée par preparedPaymentRequest
        // à notre plateforme via votre serveur.
    } failure:^(NSError *error) {
        // Indiquez qu'une erreur s'est produite.
    }
];

6. Finaliser la transaction

Après avoir reçu les données chiffrées, transmettez-les à votre application serveur pour finaliser le paiement en envoyant une requête CreatePayment.

Enfin, vous devez transmettre l'information à l'application Client pour afficher le résultat de la transaction à vos clients.

Objets SDK

Le SDK inclut plusieurs objets. Choisissez l'objet qui vous intéresse dans la liste ci-dessous pour en savoir plus :

• OPC2sCommunicator
• OPSession
  • Device Metadata
• OPPaymentContext
  • OPAmountOfMoney
• OPBasicPaymentItem Interface
  • OPBasicPaymentProduct
  • OPPaymentProduct
    • OPPaymentProductField
• OPAccountOnFile
• OPDisplayHints
  • OPToolTips
  • OPFormElement
• OPPaymentRequest
• OPPreparedPaymentRequest
• OPResponses

OPC2sCommunicator

C'est le principal service de communication. Vous ne l'utilisez pas directement, mais uniquement via l'objet Session. Il crée une connexion sécurisée avec notre API Client.

OPSession

OPSession est le composant principal du SDK. L'objet

• Enveloppe C2sCommunicator en implémentant toute la logique de communication avec notre API Client.
• Crée les demandes API appropriées.
• Est responsable de la conversion des réponses de l'API en objets natifs simples.
• Dispose d'un chiffrement intégré des objets natifs décrivant la requête de paiement de manière que notre API Serveur puisse la traiter.

Assurez-vous d'initialiser correctement Session pour commencer la communication avec notre API Client. Les propriétés obligatoires sont

• client session identifier
• customer identifier
• client-api-url
• asset-base-url

Vous obtiendrez ces paramètres en utilisant le CreateSession à partir de l'API endpoint de l'API Serveur. Consultez les SDKs Serveur et l' API Serveur pour en savoir plus.

La classe OPC2sCommunicatorConfiguration possède des méthodes statiques pour initialiser Session.

NSString *clientSessionId = @"1234";
NSString *customerId = @"5678";
NSString *clientApiURL = @"https://clientapi.com";
NSString *assetBaseURL = @"https://asset.com";
NSString *appIdentifier = @"Application Exemple/v1";

OPSession *session = [OPSession sessionWithClientSessionId:clientSessionId customerId:customerId baseURL:clientApiURL assetBaseURL:assetsBaseURL appIdentifier:kOPApplicationIdentifier];

Assurez-vous de déterminer si l'application fonctionne en production et spécifiez l'identifiant de l'application lors de l'initialisation. Un paramètre supplémentaire spécifie l'adresse IP. L'adresse IP et l'identifiant de l'application sont utilisés dans les Device Metadata lors de la communication avec l'API Client.

Propriétés

string clientSessionId : L'identifiant de la session créée string customerId : La session est basée sur le client sous la forme de customerId. Toutes les APIs Client utilisent cet customerId dans l'URI pour identifier le client string clientApiUrl : L'URL de base spécifique au centre de données pour les requêtes Client. Passez cette valeur au SDK Client pour vous assurer que le logiciel Client se connecte au bon centre de données string assetBaseUrl : L'URL de base spécifique au centre de données pour les actifs string appIdentifier : L'identifiant de l'application

Device Metadata

Les Device Metadata comprennent les données suivantes :

Propriétés

platformIdentifier : Contient la version et le type du système appIdentifier : L'identifiant de l'application fourni par l'utilisateur, sinon défini sur "unknown" sdkIdentifier : La version du SDK Client sdkCreator : Le nom de l'éditeur du SDK Client screensize : La taille de l'écran de l'appareil deviceBrand : Le fabricant de l'appareil deviceType : Le modèle de l'appareil ipAddress : Le paramètre optionnel avec l'adresse IP publique de l'appareil

OPPaymentContext

Les instances de la classe OPPaymentContext contiennent les informations de paiement les plus pertinentes, telles que :

• OPamountOfMoney
• currency
• countryCode
• isRecurring – une indication pour savoir si le paiement est un paiement unique ou un Card On File.

Ce objet :

• Participe aux étapes suivantes de la transaction.
• Doit rester sous la même forme après l'initialisation – vous devez utiliser le même objet tout au long du processus de transaction.

OPAmountOfMoney

Ce modèle contient des informations sur le montant du paiement. Il se compose du amount exprimé en type long et de la devise donnée sous currencyCode.

Notez que le montant inclut les fractions de devise. L'objet ci-dessous est égal à 1 EUR.

"amountOfMoney": {
            "amount": 100,
    "currencyCode": "EUR"
        },

Interface OPBasicPaymentItem

L'interface principale de BasicPaymentItem est principalement responsable de l'identification et de la présentation visuelle facile de l'élément de paiement. Elle possède :

• Un identifiant Id.
• Une liste de DisplayHints qui contient l'annonce textuelle visuelle (par exemple, un logo ou l'image de la carte avec le CVC marqué).
• Une caractéristique distinctive de la méthode de paiement (par exemple, un logo).
• Des informations sur les instances AccountOnFile associées.

OPBasicPaymentProduct

Le modèle principal d'un moyen de paiement. Il contient une liste de méthodes de paiement disponibles. Le client peut sélectionner une méthode parmi cette liste. Chaque instance contient :

• Un identifiant.
• Un champ indiquant la méthode de paiement de ce produit.
• Deux champs indiquant le montant minimal et maximal requis pour payer avec ce moyen de paiement.
• Un champ indiquant si notre plateforme peut stocker les données de paiement en tant que compte enregistré pour les paiements ultérieurs.
• Un champ indiquant si la méthode permet l'utilisation du Card On File.
• Un champ indiquant si la méthode de paiement utilise une redirection vers un tiers.
• Une liste des comptes enregistrés précédemment pour ce moyen de paiement.
• Affiche des indices pour rendre correctement l'OPBasicPaymentProduct, contenant :
  • Un index indiquant à quelle position appartient le moyen de paiement dans une liste de moyens de paiement
  • Un label
  • Un logo

OPPaymentProduct

Il étend la classe OPBasicPaymentProduct et implémente l'interface OPPaymentItem qui complète le modèle avec la liste OPPaymentProductField. Cependant, une fois que le client sélectionne un moyen de paiement ou un compte enregistré, il doit fournir des informations supplémentaires (par exemple, une adresse, un numéro de compte bancaire, un numéro de carte de crédit ou une date d'expiration) pour traiter le paiement réel.

Chaque moyen de paiement peut comporter plusieurs champs que le client doit compléter pour traiter les paiements. Les instances de OPPaymentProductField représentent des informations sur les champs des moyens de paiement. Utilisez-les pour récupérer des instances d'OPPaymentProduct :

// Obtenir le OPPaymentProduct sélectionné

[session paymentProductWithId:paymentProductId context:context 
    success:^(OPPaymentProduct *paymentProduct) { 
        // Créer une requête de paiement en utilisant le moyen de paiement représenté par paymentProduct. 
    } failure:^(NSError *error) { 
        // Indiquer qu'une erreur s'est produite. 
    } 
]; 
  
// Obtenir tous les OPBasicPaymentItems disponibles pour paymentContext

[session paymentItemsForContext:context groupPaymentProducts: NO success:^(OPPaymentItems *paymentItems) { 
    // Permettre au client de sélectionner un moyen de paiement et éventuellement 
    // un compte enregistré dans la liste des moyens de paiement 
    // représentée par paymentItems. 
} failure:^(NSError *error) { 
    // Indiquer qu'une erreur s'est produite. 
}];

OPPaymentProductField

OPPaymentProductField représente les champs des moyens de paiement. Chaque champ a :

• Un identifiant
• Un type
• Une définition des restrictions qui s'appliquent à la valeur du champ
• Des informations sur la façon de présenter le champ au client dans l'interface utilisateur

Le modèle possède une méthode intégrée de validation des données pour déterminer si une valeur donnée est valide pour le champ. La méthode est basée sur OPDataRestrictions. Elle retourne des OPValidationErrorMessages et des méthodes pour masquer et démasquer la valeur par le biais de StringFormatter intégré.

Le fragment de code ci-dessous montre comment récupérer le champ ayant l'identifiant "cvv" d'un moyen de paiement. Dans ce processus, nous :

• On inspecte les restrictions de données du champ pour voir si ce champ est requis ou facultatif.
• On inspecte les indices d'affichage du champ pour voir si les valeurs fournies par un client doivent être obfusquées dans une interface utilisateur.
• On Valide la valeur "123".
• On Inspecte le nombre d'erreurs de validation pour voir si la valeur fournie est valide.

OPPaymentProductField *field = [paymentProduct paymentProductFieldWithId:@"cvv"];
BOOL isRequired = field.dataRestrictions.isRequired;
BOOL obfuscate = field.displayHints.obfuscate;
[field validateValue:@"123"];
BOOL validValue = field.errors.count == 0;

OPAccountOnFile

OPAccountOnFile représente des informations sur un compte enregistré pour un certain moyen de paiement. Il contient :

• Un identifiant pour le compte enregistré.
• Un identifiant pour le moyen de paiement correspondant.
• Une collection de paires clé-valeur stockées en tant que partie du compte enregistré.
• Des indices d'affichage contenant des informations sur la façon d'afficher le compte enregistré.
• Une méthode qui produit une étiquette décrivant le compte enregistré.

Récupérez des instances de OPAccountOnFile en tant qu'instances de OPBasicPaymentProduct comme suit :

OPDisplayHints

OPDisplayHints sont des objets contenant des indications. Il existe trois types de OPDisplayHints :

• OPDisplayHintsPaymentItem : Les informations les plus importantes sur OPPaymentItem, c'est-à-dire un nom et un logo. Une propriété supplémentaire est displayOrder qui indique l'ordre d'affichage approprié selon l'indice de l'ordre par rapport aux autres OPPaymentItems utilisés par OPBasicPaymentItems et OPBasicPaymentProducts. Utilisez-les pour afficher la liste de sélection de OPPaymentItem.
• OPDisplayHintsAccountOnFile : La liste contenant les paires clé-valeur de OPProductFields et le masque correspondant pour appliquer le masque (par exemple des astérisques) à la valeur correspondante de OPAccountOnFile.
• OPDisplayHintsProductFields : Définit la manière d'afficher OPProductFields. En plus du nom et de l'espace réservé, il contient OPPreferredInputType, basé sur lequel vous pouvez choisir :
  • Le type de clavier approprié que vous devriez utiliser.
  • Si l'élément doit toujours être affiché comme AlwaysShow.
  • Si la valeur Obfuscate doit être obfusquée, ainsi que la valeur de Mask – une référence à l'OPToolTip et OPFormElement assignés.

OPToolTips

OPToolTips facilitent la saisie des données. Vous pouvez ajouter un objet ToolTip dans les indices d'affichage pour ProductFields. Il peut contenir un texte explicatif ou un graphique, par exemple une photo d'une carte avec un CVV masqué.

OPFormElement

Une description simplifiée de l'élément visuel vous indiquant comment l'utiliser correctement comme texte, liste, devise, date ou booléen.

OPPaymentRequest

Cette classe encapsule la relation entre le OPPaymentProduct sélectionné, OPAccountOnFile et les valeurs saisies. Elle vous permet d'extraire facilement des valeurs masquées ou non masquées. Elle contient une méthode de validation des données saisies. Consultez le chapitre dédié au chiffrement pour plus d'informations.

OPPreparedPaymentRequest

L'instance de la classe OPPreparePaymentRequest est le résultat du chiffrement d'une requête à l'aide d'une instance de OPSession. Elle possède deux propriétés, encryptedFields et encodedClientMetaInfo – les chaînes qui doivent être envoyées à notre plateforme. Consultez le chapitre dédié au chiffrement pour plus d'informations.

Réponses

• ApiResponse : Chaque requête est enveloppée dans une réponse API contenant des données génériques. En cas d'erreur, dans le champ supplémentaire ErrorResponse, vous pouvez trouver ApiErrorCode et Message décrivant l'erreur.
• OPPublicKeyResponse : API client que vous utilisez pour récupérer une clé publique spécifique à une transaction depuis notre serveur. Utilisez-la pour chiffrer les données sensibles, c'est-à-dire les détails de la carte. Cet objet retourne automatiquement une clé publique déjà déchiffrée depuis notre API.

Fonctionnalités Additionnelles

Le SDK offre bien plus encore. Jetez un œil aux fonctionnalités suivantes, car elles vous aideront à construire la solution parfaite.

• Chiffrer les données sensibles
• Valider les données
• Appliquer la vérification IIN
• Implémenter des paiements natifs
• Utiliser OPAssetManager
• Localiser l'application
• Utiliser le journal
• Utiliser l'application de démonstration

Chiffrer les données sensibles

L'un des plus grands atouts du SDK est son outil de chiffrement. Il offre une grande sécurité lors du transfert de données sensibles (c'est-à-dire les numéros de carte, la date d'expiration, le code CVC). Un flux de chiffrement/transfert complet ressemble à ceci :

Vous n'avez pas besoin de réaliser toutes ces étapes par vous-même. Grâce au SDK, vos tâches sont les suivantes :

1. Lorsque vos clients complètent toutes les informations de paiement requises et confirment le paiement, créez l'objet OPPaymentRequest, assignez-lui le OPPaymentProduct sélectionné et remplissez-le avec les valeurs saisies.
2. Validez l'OPPaymentRequest créé à l'aide de la méthode Validate.
3. S'il n'y a pas d'erreurs de validation, utilisez un objet Session et appelez la méthode OPPreparePaymentRequest. Elle effectuera tout le processus de chiffrement pour vous et renverra les données chiffrées.
4. Envoyez les données chiffrées à votre serveur.
5. Votre serveur envoie les données chiffrées en utilisant la méthode CreatePayment dans le champ de corps de la requête – encryptedCustomerInput.
6. Vous envoyez le résultat de la transaction à l'application cliente.

L'algorithme utilisé est RSA-OAEP avec un encodage A256CBC-HS512. Il est possible de mettre en œuvre votre propre chiffrement, mais vous perdrez la fonctionnalité d'assistance offerte par l'encrypteur. Nous ne garantissons pas le bon fonctionnement en cas de données mal chiffrées. Notez que nous ne sommes pas en mesure de vérifier les données chiffrées pour détecter des erreurs. Par conséquent, vous devez vous assurer que toutes les opérations précédentes ont été effectuées correctement.

Valider les données

Chaque OPaymentProductField possède des OPDataRestrictions appropriées. L'objet OPDataRestrictions contient des informations sur tous les champs obligatoires et valide si les valeurs saisies respectent la condition de validité. En plus d'une liste de validateurs abstraits, il possède également une propriété isRequired indiquant si les restrictions données sont requises ou non.

Vous pouvez valider une entrée particulière aussi facilement que par la validation d'un OPaymentRequest. En cas d'erreurs, le champ Errors affichera une liste d'erreurs.

Il contient les validateurs suivants :

• Expiration Date : Vérifie si la date d'expiration de la carte saisie n'est pas antérieure à la date actuelle et si elle ne dépasse pas la limite de vingt-cinq ans à venir.
• Email Address : Vérifie le format de l'adresse e-mail fournie par le client.
• Fixed List : Vérifie si la valeur saisie figure sur la liste des possibilités.
• IBAN : Valide l'IBAN fourni par le client.
• Length : Vérifie si la valeur saisie est plus longue que la valeur minimale et si elle ne dépasse pas la valeur maximale.
• Luhn : La formule de somme de contrôle utilisée pour valider divers numéros d'identification, tels que les numéros de carte de crédit.
• Range : Vérifie si la valeur est supérieure à la valeur minimale et si elle ne dépasse pas la valeur maximale.
• Regex : Valide que la valeur saisie correspond à l'expression régulière.
• TermsAndConditions : Le validateur booléen pour le champ d'acceptation des conditions générales.

Chaque validateur renvoie une erreur appropriée, indiquant un champ qui ne respecte pas les conditions, ainsi qu'un message que vous pouvez traduire facilement.

Appliquer la vérification IIN

Les huit premiers chiffres d'un numéro de carte de paiement sont connus sous le nom de Numéro d'Identification de l'Émetteur (IIN).

Vous pouvez utiliser une instance de OPSession pour vérifier quels moyens de paiement sont associés à un IIN. La vérification est effectuée de manière asynchrone, donc le résultat n'est pas disponible immédiatement. Le résultat est une instance de OPIinDetailsResponse. Cette classe possède les propriétés suivantes :

• paymentProductId : Le moyen de paiement principal associé à cet IIN.
• countryCode : Le code du pays du moyen de paiement principal associé à cet IIN.
• status : Type de OPIinStatus qui indique le résultat de la vérification de l'IIN. Les statuts possibles sont :
  • SUPPORTED: L'IIN est associé à un moyen de paiement disponible sur notre plateforme.
  • UNKNOWN: L'IIN n'est pas reconnu.
  • NOT_ENOUGH_DIGITS: Moins de six chiffres ont été fournis.
  • EXISTING_BUT_NOT_ALLOWED: L'IIN est reconnu, mais il ne peut pas être utilisé pour le paiement actuel.
• isAllowedInContext : Indique s'il est possible d'effectuer un paiement avec le moyen de paiement principal basé sur le OPPaymentContext
• coBrands : Une liste d'instances de OPIinDetail, qui représentent des co-marques pour l'IIN actuel.

Il est possible qu'une seule carte de crédit soit associée à plusieurs marques et soit ainsi « co-brandée ». Les détails du premier moyen de paiement que vos clients peuvent utiliser pour effectuer le paiement dans ce contexte sont toujours stockés dans les champs de niveau supérieur de OPIinDetailsResponse. Si le co-branding s'applique, la liste des instances de OPIinDetail contient toutes les marques associées à la carte, y compris le moyen de paiement qui est stocké dans les champs de niveau supérieur. Utilisez cette liste pour permettre aux clients de choisir leur marque préférée. S'il n'y a qu'un seul moyen de paiement associé à la carte de crédit, la liste des détails IIN est vide.

- (void)doIINLookup {
    NSString *unmasked = [paymentRequest unmaskedValueForField:@"cardNumber"];
    [session IINDetailsForPartialCreditCardNumber:unmasked context:context success:^(OPIINDetailsResponse *response) {
        if (response.status == OPSupported) {
            if (response.coBrands != nil) {
                if ([self isSelectedPaymentProductInCoBrands:response.coBrands] == NO) {
                    [self switchToPaymentProduct:response];
                }
                // La législation de l'UE exige que, dans le cas d'une
                // carte avec plusieurs marques, un client puisse choisir
                // avec quelle marque il souhaite effectuer le paiement.
                [self showCoBrandNotification];
            }
            else if ([response.paymentProductId isEqualToString:self.paymentProductIdentifier] == NO) {
                [self switchToPaymentProduct:response];
            }
        }
        else {
            // Gérer les autres codes de statut
        }
    } failure:^(NSError *error) {
        // Indiquer qu'une erreur s'est produite.
    }];
}

-(BOOL)isSelectedPaymentProductInCoBrands:(NSArray *)cobrands {
    for (OPIINDetail *cobrand in cobrands) {
        if ([cobrand.paymentProductId isEqualToString:self.paymentItemIdentifier]) {
            return true;
        }
    }
    return false;
}

- (void)switchToPaymentProduct:(OPIINDetailsResponse *)response {
    if (response.isAllowedInContext) {
        // Passer au moyen de paiement qui est effectivement dans le niveau supérieur
        // de la réponse IIN Details.
        self.paymentItemIdentifier = response.paymentProductId;
    }
    else {
        // Fournir au client un message d'erreur indiquant que le
        // numéro de carte de crédit qu'il saisit ne peut pas actuellement être utilisé pour le paiement.
    }
}

- (void)showCoBrandNotification() {
    // Montrer au client qu'il peut choisir une autre marque pour payer.
}

Mettre en œuvre les paiements natifs

Par paiements natifs pour les appareils mobiles, nous entendons Google Pay pour Android et Apple Pay pour les appareils iOS. Notre système prend en charge les paiements natifs, mais cela ne signifie pas qu'ils seront disponibles sur tous les appareils.

Si l'utilisateur reçoit un moyen de paiement responsable du paiement natif, le SDK vérifie automatiquement si l'appareil est capable de gérer le paiement. Si l'appareil ne satisfait pas aux conditions, ce paiement est masqué. Grâce à cette procédure, vous, en tant qu'utilisateur de notre produit, n'avez pas à vous soucier de vérifier la validité de l'opération.

Pour les appareils avec iOS, vous vérifiez si le système répond au critère de version minimale (8.0) et utilisez le PKPaymentAuthorizationViewController pour vérifier s'il est possible de réaliser la transaction.

Utiliser OPAssetManager

Chaque SDK possède un OPAssetManager intégré, ce qui facilite la gestion des images liées aux moyens de paiement. Pour réduire le temps de chargement et fournir une sécurité adéquate en cas de problèmes avec des ressources externes, les SDK ont des éléments de base attachés qui sont correctement associés aux moyens de paiement appropriés. De plus, le mécanisme de cache offre des performances accrues.

OPAssetManager met automatiquement à jour les ressources lors du téléchargement des moyens de paiement.

Localiser l'application

Notre SDK propose des étiquettes qui ont été traduites dans plus de cinquante langues. Grâce à cela, vous pouvez facilement traduire des messages, des codes de réponse ou des données de paiement en contenu pertinent pour l'utilisateur final.

Vous pouvez trouver un exemple de l'utilisation des traductions dans l'application de démonstration. Ci-dessous, vous pouvez voir un exemple de traduction pour les champs du moyen de paiement.

#define kOPAppLocalizable       @"OPTranslations"
 
static NSBundle * _sdkBundle;
+ (NSBundle *)sdkBundle {
    if (_sdkBundle == nil) {
        _sdkBundle = [NSBundle bundleWithPath:kOPSDKBundlePath];
    }
    return _sdkBundle;
}
 
- (NSString *)switchFormRowFromField:(OPPaymentProductField *)field paymentItem:(NSObject
  
    *)paymentItem
{
    NSString *labelKey = [NSString stringWithFormat: @"gc.general.paymentProducts.%@.paymentProductFields.%@.link.label", paymentItem.identifier, field.identifier];
    NSString *labelValue = NSLocalizedStringWithDefaultValue(labelKey, kOPSDKLocalizable, [OPFormRowsConverter sdkBundle], nil, @"");
  
    return labelValue;
}

  

Utiliser la logging

Dans certains cas, vous pouvez vouloir activer la logging des requêtes et des réponses qui composent la communication avec notre plateforme.

Vous pouvez activer la logging en démarrant AFNetworkActivityLogger au démarrage de l'application.

Utiliser l'application de démonstration

L'application d'exemple illustre les possibilités du SDK et des services proposés par notre plateforme. Trouvez le code source sur GitHub. Vous pouvez utiliser ce code comme base de votre application. L'application d'exemple se compose de quatre écrans :

• Le premier écran requête les informations nécessaires pour communiquer avec l'API Client et récupérer une liste de moyens de paiement. Cet écran ne devrait pas faire partie d'une application réelle dans le magasin d'applications. Nous le fournissons pour illustrer les informations nécessaires pour initialiser une instance de IDSession
• Le deuxième écran est un écran de sélection de moyen de paiement généré dynamiquement. En fonction des informations fournies sur le premier écran, l'application affiche une liste de moyens de paiement disponibles et de accounts on file (compte  enregistrés). Cet écran ou un écran similaire ferait typiquement partie d'une application réelle. Voir plus de détails ci-dessous.
• Après avoir sélectionné un moyen de paiement, l'application affiche le troisième écran pour obtenir l'entrée du client. Le client ne peut confirmer le paiement que lorsque le SDK a validé l'entrée. Cet écran ou un écran similaire ferait également partie d'une application réelle. Voir plus de détails ci-dessous.
• Le quatrième écran indique que le SDK a traité avec succès le paiement initié. Cet écran ne devrait pas faire partie d'une application réelle.

Écran de sélection de moyen de paiement

L'écran de sélection de moyen de paiement fournit un exemple pour l'une des deux écrans qui apparaîtront dans la plupart des applications utilisant le SDK. Il montre une liste d'articles de paiement disponibles et de comptes enregistrés. Pour chaque article de paiement / compte enregistré, il affiche un nom localisé/une courte description de l'information stockée. Si un logo est disponible pour un article de paiement, l'écran l'affichera.

L'écran contient une partie d'une liste d'articles de paiement disponibles, générée à partir des informations contenues dans une instance de IDPaymentItems.

Écran du formulaire de saisie de moyen de paiement

Cet écran est un autre exemple d'écran qui apparaîtra dans la plupart des applications utilisant le SDK. L'application l'affiche après la sélection d'un article de paiement ou d'un account on file (compte enregistré). Si le client a sélectionné un account on file (compte enregistré), certaines des valeurs requises seront préremplies et ne pourront pas être modifiées. Le formulaire de saisie est généré à partir d'une instance de OPPaymentProduct.

Validation du formulaire

L'application d'exemple utilise le SDK pour valider les entrées du client fournies lorsqu'ils appuient sur le bouton Payer. Si les données fournies sont invalides, des messages d'erreur s'affichent sous les valeurs invalides.

Informations supplémentaires

Certains champs de moyens de paiement peuvent nécessiter des explications supplémentaires. Le bouton d'information à côté du champ de texte pour le code CVV, illustré ci-dessous, indique que des informations supplémentaires sont disponibles. L'image affichée lorsque le client appuie sur le bouton fait partie des indices d'affichage du champ de moyen de paiement. L'explication textuelle est une chaîne localisée qui fait partie du SDK.

Vérification de l'IIN

L'application d'exemple démontre également l'utilisation de la vérification de l'IIN décrite ci-dessus. Pour chacun des moyens de paiement basés sur carte, une vérification de l'IIN est effectuée une fois que le client a saisi six chiffres ou plus dans le champ de texte pour le numéro de carte. Si l'IIN est associé au moyen de paiement sélectionné, le logo de ce moyen de paiement apparaît sur le côté droit du champ de texte. Si l'IIN est associé à un autre moyen de paiement, les champs de saisie sont automatiquement remplacés par les champs de saisie pour le nouveau moyen de paiement.

La capture d'écran montre également comment les co-marques qui peuvent être associées à une certaine carte peuvent être rendues. Le logo du moyen de paiement et le nom des co-marques sont récupérés en effectuant des appels spécifiques pour eux.