Account Creation failing with Error when using ASN.1 encryption key

For Account Creation I tried sending base64 encoded encrypted data (encrypted using key generated via CreateKey API). I am getting **500** error with EC: **3C451372** # Details: **(1) Endpoint**: Create Account **(2) Request Body:** > const body = { > "referenceID": grTo7EQixHbEgQq, > "card": { > "keyID": xuMKYzTSSQg8AvMOxo5v9g, > "data": R12GLdX4kKrevO0zZCiiK1SVzDeIWqaonPq5RXQ4aYH-\_\_\_Emcj-GPS2hl860IP-2hW-fq5ECNtra-9da0phJBDnd9WdRfFCbfDvpXWQH1e5IF_Ys9WRs5CEYXarj0hARv_kVJJO2sklhTEy8zyfniork59BUfbQqaLKOkDdnM1qsgnavNP7pK3Bq5E6ZqTxd_5d05i5lwSP34U6-V4DIkhQXib9KVuv9lulpHfrD-4arj4k4I0CzwyFHKhb6yEB-XmlifvO2u36K_7eFGRQKDWY0OL3OlFEWrTjCgq-KQHo3RP4mY1H-y6iJ2_y93yMyGHQPhru1wej_5-lNYEQ_Q, > }, > "owner": { > "name": { > "first": placeholderName, > "last": placeholderName, > }, > }, > "phone": { > "number": placeholderNumber, > }, > }; Sending the stringified version of body.

Introducing Dark Mode for Developer Docs

You can now view TabaPay Developer docs in dark mode by following these steps: 1. While in light mode, go to the top right and click the sun icon on the top right. 2. Dark mode should appear. ![Light Mode Docs]( To return to light mode just click the moon icon at the top right. ![Dark Mode](

Account Type in the Payout processed file

In the latest Payout Processed file we received from tabapay, there is a `B` account type in the ProcessedFile which cause the parsing failure in our system. <br> But from <>, the account type does not include a `B` value at all. Business checking and Business saving are `BC` and `BS` respectively.

Questions about Soft Descriptor use

The [documentation for the Soft Descriptor]( says that some characters are explicitly restricted. Since one of the Soft Descriptor fields is an email address, and the @ character is explicitly restricted, are we to understand that the restrictions are only for the `name` field? There is a table for Visa Guidelines. That table has a Field column, but from the row values it appears that the Field is always the `name` field of the Soft Descriptor, and that the only difference between the two rows in the table is that the first row is for push transactions and the second row is for pull transactions. The first row includes "Card Acceptor _City_ Name", and I concluded that "City" is incorrect. The Soft Descriptor documentation does not mention "Card Acceptor" any of its fields, so assuming the "Card Acceptor Name" = `name`. The [Statement Descriptor documentation]( topic describes using an asterisk as a delimiter for both push and pull operations, and describes `{processor}*{person name}` as the content for person-to-person payments. In the Visa Guidelines the documentation for the _push_ row shows: > **P2P**: P2P > Brandname_Sender > Name Does that mean that the `name` should be `P2P {processor} {person name}`, rather than `{processor}*{person name}` as described in the Statement Descriptor documentation? (Some of the other types in that row show an underscore character, which is also not shown in the Statement Descriptor documentation.) The documentation in the pull row seems to match the Statement Descriptor documentation. The \[MasterCard Guidelines](<>) seem to indicate that a space/blank should be the delimiter, and therefore that the asterisk is not appropriate for the delimiter. Is that accurate? We appreciate the documentation regarding the descriptor because finding it in the card processor documentation is challenging.

JSON Content-types for responses

Hello :wave: Per our discussion \[here](<>) we discussed TabaPay updating all API endpoints' content-type headers to JSON. I was wondering if there's an update to that. We're refactoring our network module and finding it difficult to override our responses from TabaPay accordingly. Thanks!

Create Card allows 1 char for first/last name, but 3ds/lookup requires 2 chars

The \[Query Card](<>), \[Create Account](<>), and \[Create Transaction](<>) API calls all allow a single character for the `first` name and `last` name fields for the owner, but the \[3D Secure Lookup](<>) call requires 2 characters in both. The 2-character requirement is not documented and is inconsistent. I realize that the back-end API that you're using requires a minimum of 2 characters for first and last names, but this should be called out in the documentation, especially because it is inconsistent.

Query Card with AVS expiry date validation

Query Card with AVS validates CVV properly but it doesn't validates expiry date. I tried query card with correct account number, cvv and wrong expiry date but it didn't give any error. I thought we were suppose to get error regarding invalid expiry in networkRC but it has 00 value in all cases. Does Query card with AVS validates expiry date? If yes, where is it represented?

We've noticed a lot of declined payment attempts

Hi, We are seeing a lot of declines for payments on cards that have been used before. For example, two different Mastercards were declined with a NC of 82. On another Visa card, we received a NC 59. An hour later, the card was used and the payment was accepted. Any reason why this is occuring?

3-D Secure: JWT validation after continueWithTransaction?

The [documentation for JWT validation]( says that the response from the mobile SDKs continueWithTransaction... method can be validated by calling the [TabaPay 3D Secure Authenticate API]( That API appears to be required but is not mentioned in the [sequence diagram]( By the way, that sequence diagram is _incredibly helpful_, which is why I'm pointing out the potential gap.

iOS 3DS challenge Flow callback

I am following the to implement 3DS. I am able to successfully create Frictionless transactions as well as transactions that have Step up/Challenge response. However, the behavior I am seeing is slightly different from what the guide states. When I use sandbox test card for lookup Challenge/StepUp from specifically 4000000760000002, I get the challenge and I get the JWT in the callback but the validateResponse is nil. I am able to successfully create transactions with the JWT returned in this callback, but there is no way to check the actionCode ``` func cardinalSession(cardinalSession session: CardinalSession!, stepUpValidated validateResponse: CardinalResponse!, serverJWT: String!) { switch validateResponse.actionCode { case .success: // Handle successful transaction, send JWT to backend to verify break case .noAction: // Handle no actionable outcome break case .failure: // Handle failed transaction attempt break case .error: // Handle service level error break case .cancel: // Handle transaction canceled by user break case .timeout: // Handle transaction timedout break } } ``` Am I doing something wrong or should I ignore the `validateResponse.actionCode` in step 12 of this guide. Thanks!