Payment flow

• Generate a client token
• Render a checkout page to collect customer payment information
• Verify the credit card and amount via the BTThreeDSecureDriver class
  • If the customer's card is enrolled in a 3D Secure program, the customer may be prompted to authenticate using their bank login credentials

Generate a client token

Before you can initialize BTThreeDSecureDriver, you will need to set up the SDK and initialize with a client token generated on your server.

Update your Podfile to include the 3D Secure subspec, like this:

pod 'Braintree'
pod 'Braintree/3D-Secure'

Specify a merchant account

If you would like to use a merchant account ID other than your default, specify the merchant_account_id when generating the client token.

Render a checkout page

You can structure your native checkout flow however you'd like. If you don't already have a credit card form, consider our Drop-in UI.

Start by adding an import statement:

#import "Braintree3DSecure.h"

@interface YourCheckoutViewController () <BTViewControllerPresentingDelegate>

@property (nonatomic, strong, readwrite) BTThreeDSecureDriver *threeDSecure;

@end

@implementation YourCheckoutViewController

When the user taps on the final checkout button, but before creating a transaction on your server, you should show a loading indicator to the user and initialize for 3D Secure:

- (void)prepareForCheckout {
    // Retain both your instance of `BTThreeDSecureDriver` and its delegate with a strong pointer to avoid memory-management bugs.
    self.threeDSecure = [[BTThreeDSecureDriver alloc] initWithAPIClient:self.apiClient delegate:self];
}

Your view controller should conform to BTViewControllerPresentingDelegate in order to handle view controller presentation. Your loading indicator should be hidden when paymentDriver:requestsPresentationOfViewController: is received.

Verify a credit card

You can verify transactions with verifyCardWithNonce:amount:completion:. This call will refer to the card data based on the payment method nonce and may challenge the cardholder with a 3D Secure authentication, if the card is enrolled in a 3D Secure program and the card-issuing bank requires this verification.

The transaction amount is required at verification for two reasons. First of all, it's an additional check to make sure the transaction being verified is the same as the one that is eventually authorized and settled. For this reason, the amount submitted for verification must match the amount sent to the Braintree server for authorization. Additionally, some issuers use the amount to help determine whether they should challenge the user to authenticate.

- (IBAction)tappedCheckout {
    // Create a BTCard based on the UI state
    BTCard *details = [[BTCard alloc] init];
    details.number = self.cardNumberField.text;
    details.expirationMonth = self.expirationMonthField.text;
    details.expirationYear = self.expirationYearField.text;

    // Tokenize the card
    [self.cardClient tokenizeCard:details completion:^(BTCardNonce *tokenizedCard, NSError *error) {
        if (error) {
          // Handle errors
          return;
        }

        // Kick off 3D Secure flow. This example uses a value of $10.
        [self.threeDSecure verifyCardWithNonce:tokenizedCard.nonce
                                        amount:[NSDecimalNumber decimalNumberWithString:@"10"]
                                    completion:^(BTThreeDSecureCardNonce *card, NSError *error) {
                                        if (error) {
                                            // Handle errors
                                            return;
                                        }

                                        // Use resulting `card`...
                                    }];
    }];
}

If a user-facing authentication flow is required, the delegate will receive a view controller, which you must present to the user:

- (void)paymentDriver:(id)driver requestsPresentationOfViewController:(UIViewController *)viewController {
    [self presentViewController:viewController animated:YES completion:nil];
}

- (void)paymentDriver:(id)driver requestsDismissalOfViewController:(UIViewController *)viewController {
    [self dismissViewControllerAnimated:YES completion:nil];
}

If the user successfully completes the 3D Secure process, the callback block will receive a BTThreeDSecureCardNonce. You should transmit the nonce to your server and create a transaction.

// Kick off 3D Secure flow. This example uses a value of $10.
[self.threeDSecure verifyCardWithNonce:tokenizedCard.nonce
                                amount:[NSDecimalNumber decimalNumberWithString:@"10"]
                            completion:^(BTThreeDSecureCardNonce *card, NSError *error) {
                                if (card) {
                                      // (Optional:) Update your UI with card details
                                      self.yourCardNumberLabel.text = card.lastTwo;
                                      self.yourCardTypeLabel.text = card.typeString;

                                      // Transmit the payment method nonce to your server
                                      NSString *paymentMethodNonce = card.nonce;
                                  } else if (error) {
                                      // Handle errors
                                  } else {
                                      // User canceled
                                  }
                            }];
}];

If the user cancels the 3D Secure authentication, the completion block will be called and and both parameters will be nil.

In order to perform 3D Secure authentication again, a new nonce needs to be supplied.

If the 3D Secure process fails, the completion block will be called with an error.

For each request to verify a card, the completion block will be called exactly once.

Verify a vaulted credit card

First, on the server, generate and return a payment method nonce for the vaulted credit card.

Then on the client, you can use the verifyCardWithNonce:amount:completion: method just as before and pass it the newly-generated nonce.

Advanced client-side options

We expose additional information about the authentication request that you can use for more advanced UI flows or risk assessment. You should be aware that making such assessments may result in accepting the liability for fraudulent transactions.

These parameters pass through the client-side first and should not be trusted for your server-side risk assessment. They should be used for UI flow only.

// In this example, `card` is a `BTThreeDSecureCardNonce`.
if (card.liabilityShiftPossible && card.liabilityShifted) {
    NSLog(@"liability shift possible and liability shifted");
} else {
    NSLog(@"3D Secure authentication was attempted but liability shift is not possible");
}

1. liabilityShifted indicates that 3D Secure worked and authentication succeeded. This will also be true if the issuing bank does not support 3D Secure, but the payment method does. In both cases, the liability for fraud has been shifted to the bank. You should go on creating a transaction using the new nonce.
2. liabilityShiftPossible indicates that the payment method was eligible for 3D Secure. If liabilityShifted is false, then the user failed 3D Secure authentication. In this situation, the card brands recommend asking the user for another form of payment. However, if you have server-side risk assessment processes that allow for it, you can still use the new nonce to create a transaction. If you want to use a nonce that did not pass 3D Secure authentication, you need to set the required option to false in your server integration.
3. If both of the above values are false then this card was ineligible for 3D Secure. You can continue to create the transaction with the new nonce. However, liability shift will not apply to this transaction. This case may be useful if you would like to ask the user for additional verification (AVS, etc).

Next: Server-side →