Migreren van iOS SDK v1.0.0 naar v2.0.0

  Laatst bijgewerkt: 

 

In de volgende documentatie wordt uitgelegd wat er is veranderd tussen v1.0.0 en v2.0.0 van de iOS SDK en waar u rekening mee moet houden bij de migratie naar de nieuwste versie.

 

Veranderingen in v2.0.0

We hebben de parameters bijgewerkt die worden geretourneerd bij het voltooien van de betaling. Dit omvat nu:

  • Lijst van antwoorden op verzoeken.
  • Het veld threedresponse (indien aanwezig).
  • Eventuele fouten die zijn opgetreden.

 

Wat kan threedresponse worden gebruikt?

In v1.0.0 kon u de geretourneerde object-array (responseObjects) in transactionSuccessClosure, en vind het antwoordobject van het THREEDQUERY verzoek.

(Voorbeeld)

let threeDQueryResponse = responseObjects.filter({ $0.requestTypeDescription(contains: TypeDescription.threeDQuery) }).first

 Dan zou u de velden (threeDQueryResponse.threeDResponse of threeDQueryResponse.pares) opgeslagen in dit object om de payload voor het AUTH verzoek te genereren.

In v2.0.0 is de threedresponse object is gemaakt (dat de autorisatieparameters bevat), dat direct wordt teruggestuurd in transactionResponseClosure.

U kunt de velden (threedresponse.threeDResponse of threedresponse.pares) opgeslagen in dit object om de payload voor het AUTH verzoek te genereren.

 

transactionResponseClosure

In v1.0.0, als onderdeel van de transactionSuccessClosure en transactionErrorClosure, hebben we een geparseerd transactie responsobject teruggestuurd.

In v2.0.0 hebben we echter maar één transactionResponseClosure, omdat wij onze handelaren meer controle wilden geven over hoe zij het antwoord interpreteren. Zoals in onderstaand voorbeeld:

v2.0.0 v1.0.0
transactionResponseClosure: {
(
responseJwtList: [String],
threeDResponse: ThreeDResponse?,
error: APIClientError?
)
in}

Voorbeeldscenario

In v1.0.0, zou een verzoek van "THREEDQUERY","AUTH","SUBSCRIPTION" waarbij de THREEDQUERY en AUTH succesvol waren, maar de SUBSCRIPTION een fout vertoonde, de SDK een transactionErrorClosure, ondanks dat de THREEDQUERY en AUTH met succes zijn verwerkt. Het weergeven van een foutmelding aan de klant in dit specifieke scenario kan misleidend zijn, omdat er geld was gereserveerd op hun bankrekening.

Om de kans te verkleinen dat de klant verkeerd wordt geïnformeerd over het resultaat van de betalingstransactie, maken we in v2.0.0 niet langer op deze manier onderscheid tussen succes en mislukking, en geven we nu alleen de volledige lijst met resultaten terug die u eerst moet verifiëren, parseren en vervolgens moet analyseren de errorcode in elk van de antwoorden.

Wat het bovenstaande scenario betreft, zou u uw systeem zo kunnen configureren dat het de antwoorden THREEDQUERY en AUTH als een succes behandelt en het juiste antwoordbericht in de browser van de klant weergeeft (om aan te geven dat er geld is gereserveerd voor betaling), maar ook een foutbericht weergeeft om hen te informeren dat de automatische abonnementsbetalingen nog moeten worden gepland wegens een fout, en dat de klant wordt aangeraden contact met u op te nemen voor hulp.

Voordat informatie in het antwoordobject kan worden vertrouwd, moet u de handtekening van elk JWT-antwoord verifiëren.

Wij bieden een parsingprogramma om de gegevens uit payload velden te halen als onderdeel van de controle van de velden van het betalingsantwoord:

transactionResponseClosure: { [unowned self] responseJwtList, threeDResponse, error in

// Every JWT returned from the SDK should be verified before further usage.
let isVerified = !responseJwtList.map { JWTHelper.verifyJwt(jwt: $0, secret: self.appFoundation.keys.jwtSecretKey) }.contains(false)

AppLog.log("JWT verification status: \(isVerified)")

if !isVerified {
// throw error and show the appropriate message
return
}

// error indicating that there was a general error in connecting to the server or in 3dsecure authentication (APIClientError enum)

guard let error = error else {

// a parsing utility
guard let tpResponses = try? TPHelper.getTPResponses(jwt: responseJwtList) else { return }

// an example of how to get a card reference object which in version 1.0.0 was part of the closure (TPCardReference object)
let cardReference = tpResponses.last?.cardReference

// an example of how to get the JWTResponseObject array which in version 1.0.0 was part of the closure
let responseObjects = tpResponses.flatMap { $0.responseObjects }

// an example of how to find a response object that interests us
let riskDecResponse = tpResponses.compactMap { $0.responseObjects.first(where: { $0.requestTypeDescription(contains: TypeDescription.riskDec) }) }.first

// the error object constructed from the errorcode property (in version 1.0.0 it was part of the APIClientError class, in version 2.0.0 the TPError class was created)
guard let firstTPError = tpResponses.compactMap({ $0.tpError }).first else {

self.showAlert(controller: self.navigationController, message: LocalizableKeys.DropInViewController.successfulPayment.localizedStringOrEmpty) { _ in
self.navigationController.popViewController(animated: true)

}
return
}
if case TPError.invalidField(let errorCode, let localizedError) = firstTPError {
AppLog.log("RESPONSEVALIDATIONERROR.INVALIDFIELD: code: \(errorCode.rawValue), message: \(localizedError ?? errorCode.message)")
}

if case TPError.gatewayError(let errorCode, let error) = firstTPError {
AppLog.log("GATEWAYERROR: responseErrorCode: \(errorCode.rawValue)), errorCode: \((error as NSError).code) message: \(error.localizedDescription)")
}

self.showAlert(controller: self.navigationController, message: firstTPError.humanReadableDescription) { _ in }
return
}

self.showAlert(controller: self.navigationController, message: error.humanReadableDescription) { _ in }
}
Was dit artikel nuttig?
0 van de 0 vonden dit nuttig