About Yolanda

Yolanda

for invoice settlement enabled tenants, both processed electronic payments and processed external payments need to be first canceled then deleted. (no void operation for electronic payments any more)

Yolanda

Hi @Seb , this is actually not a support ticket a support ticket could be filed from here: https://support.zuora.com/hc/en-us/

Yolanda

Hi @Seb, happy to know we could help! So for the new issue of no 3DS2 challenge displayed, if the error only happens when 3DS2 setting is enabled, then it is better to be further investigated through a support ticket because we will need to know more info about your environment and test to find the root cause. One little suggestion, I saw you're running an environment in your local server, so by providing the HAR file together with filing the ticket will help for us to know what is happening on the client-side. (How to create a HAR file to share with support team to investigate HPM related issues)

Yolanda

How to create Stored Credential Profile for Payment Method? Approach 1: create Stored Credential Profiles together with creating new payment methods The stored credential profile could be created together with the payment method through different ways depending on how you're creating payment methods: through UI: Manage stored credential profiles for credit cards through SOAP API: PaymentMethod through REST API: Create payment method, Create credit card payment method through HPM: Add a Checkbox for Stored Credential Consent, Direct POST Fields for Stored Credentials Approach 2: create Store Credential Profiles for existing payment method For the payment methods already existing in your tenant, you could have credential profiles created for them as well. through CIT/MIT Configuration Setting: Migrate all existing payment methods for stored credential transactions What is the difference between the 2 approaches? (The explanation here is mainly for Stripe v2 Payment Gateway inplementation, could be used as reference for other gateway implementations) The major difference between these 2 approaches is we're using different features/requests provided by the payment gateways to get the necessary info to create an active profile for the payment method. To explain it in a simple way, the payment gateway requests we're calling under the 2 approaches are as below(might differ among different payment gateway implementations): Zuora Scope Payment Gateway Scope "CIT/MIT configuration setting" to handle existing Payment Method CIT request provided by Payment Gateway for existing cards checkbox/setAgreement function to handle new Payment Method grandfathering request provided by Payment Gateway for newly created cards Are both of the approaches required? Can I just use one of them? Both of them are required. What will happen if I take no action on this? If no action has been taken on this, then when it becomes a must for all transactions to be compliant with the Stored Credential Transaction framework, it is possible that: - for newly created payment methods, payment method creation might fail - for existing payment methods, the payment transaction might fail (since it is not decided by Zuora to approve or decline the transactions, so above is our understanding of the Stored Credential Transaction framework) Please also refer to the entrance page of this feature in our Knowledge Center for more details: Stored credential transactions

Yolanda

Issue Description: When trying to refund a credit memo, below error has been returned The transaction CreditMemo with id xxxxxxxxxxxxxxxxxx has been locked by another transaction, you may have to wait for sometime and try again later. But under the credit memo, there is no any related transaction displayed. Root Cause: There is a known issue that Processing refund will not be displayed in UI under the Credit Memo. So if there is already an electronic refund created on the Credit Memo and the refund has been stuck at the status of Processing, the Credit Memo will be locked and cannot be seen from the Credit Memo UI. Workaround: When the above error happens, please wait for a while and try the refund operation again. If you're still seeing the same error after 5 minutes, there is a big chance that you've encountered this issue. To find out the previous refund which stuck at Processing status, you could try either of the below methods: A. check for Processing Refund record from the refund list of the customer account https://www.zuora.com/apps/ARRefund.do?method=list&customer_id=xxxxxxxxxxxxxxxxxxx (please replace 'xxxxxxxxxxxxxxxxxxx' with the Customer Account id) B. export refund with below filter through Data Source Export After the Processing refund is located, please refer to below post to update its status to set it to its real status: https://community.zuora.com/t5/Billing-Payments/Refund-Stuck-in-Processing-status/td-p/15851 Internal Ticket Number(for tracking): SET-2383

Yolanda

Thanks for the sharing @gherry! I've tested the test card from the below section and you're right it is working! https://stripe.com/docs/testing#regulatory-cards However, I still feel the error returned for the card numbers from the "three-ds-cards" section is expected by Stripe because in their description, "Radar rules" has been mentioned many times and that is a setting on Stripe side to trigger dynamic 3D Secure authentications which have is explained in below link: https://stripe.com/docs/payments/3d-secure#three-ds-radar So my guess is that the test card numbers listed in the "three-ds-cards" section are provided for customers to test together with their Radar rules? But that's only my guess which should be confirmed with Stripe side if needed.

Yolanda

Hi @jbeckner , This might not help a lot to the issue you'd like to solve but just some information for your reference. The payment gateway specified as authGateway in the create payment method request will only be used for the Authorization request when adding the payment method. It won't affect which payment gateway will be used for the payments will be processed with this payment method. The reason there is a dependency between the account level payment gateway and the default payment method of the account is that the default payment method will be used to process payment in Payment Runs when AutoPay is enabled so we need to make sure the default payment method is supported by the account payment gateway. But the description about authGateway in our API Reference is a little confusing and we'll reach out to our documentation team to improve it. Thank you for pointing it out for us! Regards, Yolanda

Yolanda

Hi @gherry! sorry for the late reply! actuall I'm also getting the same error when using card number 4000 0000 0000 3220 for testing. I've confirmed that with our engineering team and that error is returned from Stripe side and is not something Zuora could control. I'm also referring to the same Stripe doc for testing so unfortunately don't have other card numbers to try. Regards, Yolanda

Yolanda

Hi Seb, If the payment gateway specified in your hosted payment page configuration is already Adyen Integration v2.0, then it is possible the param field_gatewayName has been used and have had the gateway overridden when sending the request to Zuora. Regards, Yolanda

Yolanda · ‎09-11-2019

(text in blue: attributes from Stipe, text in green: params from Zuora) With Stripe v1, the decline_code returned by the Stripe payment gateway is being used as GatewayResponseCode of the Payment in Zuora and there was a known issue that the decline_code could not be completely saved because of the length limitation of GatewayResponseCode. e.g. With Stripe v2, this has been fixed. The ResponseCode returned by the Stripe payment gateway is being use as GatewayResponseCode of the Payment in Zuora and type, code, decline_code (if there is any) returned by the Stripe payment gateway will be saved within GatewayResponse of the Payment in Zuora to provide more information about declined reason to customer. e.g. If you're migrating your payment gateway from Stripe v1 to Stripe v2 and there is integration relying on the value of Payment.GatewayResponseCode, please refer to above to make necessary update to your integration. Please refer to below documents from Stripe payment gateway for more information about the ERROR attributes returned by Stripe payment gateway. https://stripe.com/docs/api/errors#errors-decline_code https://stripe.com/docs/declines/codes

Yolanda · ‎09-09-2019

The 2 types are different on how they could be used in creating payment method as below 1. Create Payment Method through UI Payment Gateway Type Supported Payment Method Type Email Required? PayPal Payflow Pro Express Checkout Yes PayPal Express Checkout Native Express Checkout No 2. Create Payment Method through API Payment Gateway Type Supported Payment Method Type Email Required? PayPal Express Checkout Express Checkout Yes Native Express Checkout No PayPal Payflow Pro Express Checkout Yes Reference Links: API Reference - Create Payment Method How do I use the PayPal BAID Payment Method in Zuora?

Yolanda · ‎09-09-2019

kudoed~

Yolanda · ‎09-06-2019

Log into your Zuora tenant and go to the Hosted Pages list page If there is a column of Version in the page list, please make sure the HPM instance you're using is on 2.0 e.g. If there is no column of Version in the page list, it means all of your HPM instances are on v2.0 e.g.

Yolanda · ‎09-06-2019

Referenced Documents [Zuora Doc] PSD2 and strong customer authentication overview [Zuora Doc] Enable 3DS2 for Stripe gateway integration [Zuora Doc] Add a Checkbox for Stored Credential Consent [Stripe Doc] 3D Secure test card numbers and tokens Preparation 1) contact Stripe Support to complete necessary configuration for your Stripe account to accept requests from Zuora for 3DS2 2) contact Zuora Support to enable 3DS2 for your Zuora tenant (make sure Sandbox first) 3) configure new payment gateway instance with payment gateway type of Stripe v2 4) make sure the HPM instance being used is a v2.0 HPM How to confirm if I'm using v2.0 HPM 5) make sure setting Enable 3D Secure 2.0 has been enabled for your HPM instance and correct payment gateway has been selected 6) make the necessary change to your code of HPM implementation required change: "page id" of your HPM instance should be correctly specified as a most basic test, there was no any other param change before/during my test except the page id I've already got necessary change for CIT/MIT feature completed before this test, but if that has not been done in your HPM implementation, it will be another required change you need to have. Test access the page where your HPM instance is embedded and input the card data as usual (test card number 4000 0000 0000 3220 has been used in my test ) Common Issue 1) error 400 – [invalid_request_error/parameter_unknown] Received unknown parameter: payment_method_options[card][mit_exemption] happens when process a payment through Strip v2 with a payment method added through 3DS2 enabled HPM this error means necessary settings on Stripe side has not been configured yet, please reach out to Stripe Support to further help. 2) error 402 -- [card_error/authentication_required/authentication_required] Your card was declined. This transaction requires authentication happens when processing a payment through Strip v2 with a payment method added through 3DS2 enabled HPM when this error happens, it doesn't necessarily mean there is a problem in our integration. Our integration will send required fields to the payment gateway and reflect the response we received into the payment status. But it is out of our control why response we will receive or if the payment transaction needs an authentication. 3) there is no authentication popup triggered please confirm the description of the test card number being used in your test based on this document . authentication behavior could be different when different test case numbers being used.

Yolanda · ‎09-06-2019

APIs newly added Credit Memo Debit Memo Reverse invoice Get invoice application parts Create credit memo from invoice Create debit memo from invoice Write off invoice PAYMENTS (except the CRUD:xxxxx ones) REFUNDS (except the CRUD:xxxxx ones) REVENUE RULES REVENUE SCHEDULES APIs with update (to be added)

Yolanda · ‎09-04-2019

When using Stripe v2's 3DS2 feature, please make sure you have contacted Stripe Support to complete necessary configuration for your account to avoid below error when processing payment: 400 – [invalid_request_error/parameter_unknown] Received unknown parameter: payment_method_options[card][mit_exemption]

Yolanda · ‎08-26-2019

:) hi @tatyana, great suggestion! steps using workflow as been added

Yolanda · ‎08-26-2019

Case#2 The old payment gateway is being specified under customer accounts' setting directly with payment gateway names. Option#1 Through Connect's Developer Tools(purchasable Marketplace App) Please make sure to first test in Sandbox environment before making any change to Production environment. 1. Get account list which is using the old payment gateway instance 1) login to your Zuora Billing Service tenant and goto Reporting > Data Source Export 2) select "Account" to be the Data Source, select Fields and Filter as below: 3) click button "export", download and open the exported file 4) update the column header as below: Account: ID --> Id Account: Payment Gateway Name --> PaymentGateway 5) update the value of payment gateway name from the old payment gateway name to the new payment gateway name e.g. CyberSource API v1.97 --> CyberSource API v2.0 6) save the csv file 2. Use API Loader to bulk update the payment gateway for customer accounts Please make sure to first test in Sandbox environment before making any change to Production environment. 1) go to Marketplace > Developer Tools 2) create New Task with type of 3) update Task Name, Run Mode and select valid connection 4) open the Advanced tab and upload the file saved from 1. and create the task Reference: Generate a data Source Export Configure API Loader for Specific Zuora Objects CSV Teamplate for Account&Contact Option#2 Through 3rd Party REST API Client Tools Please make sure to first test in Sandbox environment before making any change to Production environment. Many of REST API client tools(e.g. Postman) have the feature to help customer execute REST API requests in bulk. 1. Get account list which is using the old payment gateway instance (same as option#1, skip..) 2. Use Postman to bulk update the payment gateway for customer accounts 1) create an update request under a collection, make Id and PaymentGateway to be input params 2) start Postman's Collection Runner and select the Collection where your request is saved, select the file generated from 1 to be the Data File 3) Click the Start Run button to start the bulk update and wait for the collection run to complete and check the result (Since this is an example of how to use a 3rd party tool, so we don't have further information about the limitation of records could be updated at a time and the expected performance) Reference: Starting a collection run Lo oping through a data file in the Postman Collection Runner Option#3 Through Workflow Please make sure to first test in Sandbox environment before making any change to Production environment. 1) login to your Zuora Billing Service tenant and goto Platform > Workflow 2) Create a new workflow with a Blank template 3) Add a Query step (plus sign > On Start > Retrieve > Query) and configure it as below FIELDS Tab CONDITION Tab 4) add an Iterate step (On Success > Logic > Iterate) and configure it as below 5) add an Update step (For Each > CRUD > Update) and configure it as below 6) click the little triangle to run the workflow 7) check RUN HISTORY tab and TASKS tab till workflow run completed Reference: General steps for using Workflow Workflow Tasks Option#4 Through Customized Script Please make sure to first test in Sandbox environment before making any change to Production environment. For customers having developing resources, we would also recommend using a customized script to finish the update and below are 2 API requests could help: REST API - Query REST API - Update

Yolanda · ‎08-26-2019

Case#1 The old payment gateway was the tenant level default payment gateway and all customer accounts using that payment gateway has option Use Default Gateway configured their payment gateway. Please make sure to first test in Sandbox environment before making any change to Production environment. Please configure your new payment gateway instance in Payment Gateway List page https:/[domain name]apps/NewGatewaySetting.do?method=list Click the [Make Default] for the newly configured payment gateway to change the new payment gateway to be the default one. (no other action need to be executed under each customer account)

Yolanda · ‎08-26-2019

Occasionally, our customers will need to upgrade their payment gateway to a new version. When that happens, sometimes it is also required to update the payment gateway setting of customer accounts to use the new payment gateway instance. Here is an introduction of some common approaches/tools to help. Case#1 The previous payment gateway was the tenant level default payment gateway and all customer accounts using that payment gateway has option Use Default Gateway configured their payment gateway. Click to see Option for Case#1 Case#2 The old payment gateway is being specified under customer accounts' setting directly with payment gateway names. Click to see Options for Case#2

Yolanda · ‎08-07-2019

It has been mentioned in below KC page that it is required to save transalation files with encoding ISO-8859-1 for some European languages. https://knowledgecenter.zuora.com/CB_Billing/LA_Hosted_Payment_Pages/B_Payment_Pages_2.0/D_Translate_and_Localize_Payment_Pages_2.0 Below are 2 example applications could have to save text file in different encodings(including ISO-8859-1) Mac OS: Atom Windows: Notepad++

Yolanda · ‎08-01-2019

[Issue Description] In a tenant with Invoice Settlement enabled, there should be no invoice/credit memo with a negative balance be generated anymore. However, there is a known issue that negative invoices/credit memos are still possible to be generated when all of the below conditions are met(3A or 3B): 1) The Invoice/Credit Memo generation rule in the Billing Setting has been configured to Create credit memos for net negative invoice totals without grouping charges 2) There is negative taxation item exists in the invoice 3A) The total amount of invoice item without tax is positive, but the total amount of invoice item with tax (or the total amount of invoice) is negative. 3B) The total amount of credit memo item without tax is positive, but the total amount of credit memo item with tax(or the total amount of credit memo) is negative. for 3A) Here is an example of an Invoice which got into this situation in an environment where Invoice Settlement has already been enabled. for 3B) Here is an example of a Credit Memo which got into this situation in an environment where Invoice Settlement has already been enabled. [Workaround] Currently, this situation could only be worked around by temporarily change the Invoice/Credit Memo generation rule from Create credit memos for net negative invoice totals without grouping charges to Put all negative charges on a credit memo . [Tracking Number] SET-2172, SET-2276

Yolanda · ‎07-25-2019

A. The callout parameter was not correctly configured -> The parameter should be configured in the callout is PaymentRun.PaymentRunID but not PaymentRun.ID B. The failed payment which expected to trigger the CPR was not from a Payment Run -> only failed payments from a Payment Run could trigger CPR if configured correctly C. Error code mapping was not correctly configured in CPR -> for the values in the "gateway" column, it should be the "gateway type" instead of "gateway name"

Yolanda · ‎07-24-2019

There is a new article has been posted in our Annoucement forum which will have more updates coming soon! PSD2 & SCA - what you need to know (please subscribe to the page to get notification)

Yolanda · ‎07-22-2019

please refer to below post for the latest endpoint for using REST in Production Copy environment. https://community.zuora.com/t5/API/REST-endpoint-base-URL-of-Production-Copy-Service-Environment/td-p/29611

Yolanda · ‎07-22-2019

You might encounter the error "Connection test failed. Invalid Credentials. Received fatal alert: certificate_expired." when trying to save the update secret key info. That normally indicates the p12 file uploaded for "CyberSource Transaction Security Key" in your PMU configuration has expired. (and the PMU jobs in the tenant should already be failing for a while) To have the certificate private key be re-generated, please follow the below document: Configure the CyberSource Payment Method Updater (one CyberSource merchant account could have multiple active certificates at the same time, so the newly generated key could be used only for your PMU configuration) If you're still seeing the error after regenerated and uploaded the new p12 file to you PMU instance, please contact Zuora Global Support for further assistance.

Yolanda · ‎07-19-2019

Hi Lisa, thanks for the update! If there was no error displayed when you saved the related key data, then it means the update was successful.

Yolanda · ‎07-10-2019

CyberSource has upgraded its Business Center (merchant account console). In line with this change, the process to programmatically retrieve reporting files will be migrated to use the RESTful APIs. Since this change will sunset their legacy file download servlet API that is currently being used by Zuora's CyberSource Payment Method Updater's implementation, we have updated the configuration page of CyberSource Payment Method Updater to accommodate this change. The Username/Password credential is replaced with a Shared Secret Key that will be used in RESTful APIs to get the updater report from CyberSource. [Deadline] The change will need to be completed in your production tenant by July 31, 2019. If the required change has not been completed by the date, the CyberSource Payment Method Updater will stop working. [Required Action for Customer] You will need to get the Shared Secret Key from your CyberSource Business Center and input it into Zuora's CyberSource PMU instance's configuration page. 1. How to get the Shared Secret Key from CyberSource Business Center Step 1 Log in to the new Business Center. Step 2 In the left navigation panel, choose Key Management. Step 3 Expand the Transaction Processing menu. Step 4 From the drop-down menu, choose API Keys. Step 5 Click the Add icon at the bottom of the page. Step 6 Select Shared Secret Key. Step 7 Click Generate New. Step 8 Copy the key from the user interface and save it safely(the key will only be displayed once) Step 9 Go back to Key Management change the filter to Keys: API Keys Step 10 Click the newly created key with Key Type of Shared Secret Key Step 11 Copy the Key ID (e.g. 6b432ff8-f1ed-7891-8629-ebc84w33cb16d) More details could be found in below document: Getting_Started_REST_API.pdf 2. How to update your Zuora Tenant’s CyberSource PMU instance configuration Step 1 Login to your Zuora tenant Step 2 Open the Payment Method Updater list (right-top menu) Payments > Setup Payment Method Updater https://www.zuora.com/apps/UpdaterAccount.do?method=list Step 3 Open your CyberSource payment method updater instance Step 4 Paste the Key you copied from CyberSource(Step 8) into Shared Secret Key Step 5 Paste the Key ID you copied from Cybersource(Step 11) into Shared Secret Key Id Step 6 Save (If there is no error displayed when you save the Key Id and Key, it means the update has been successfully saved. Our engineering team will also monitor from the backend and we will reach out to you if we see any issue.) Please contact Zuora Global Support if you have any questions regarding this transition. Reference Documents: CyberSource Payment Method Updater from Zuora Reporting Migration Document from CyberSource

Yolanda · ‎07-07-2019

Here is a newly added document page to explain our callout Basic Auth in detail: https://knowledgecenter.zuora.com/CF_Users_and_Administrators/Notifications/E_Configure_Callout_Notifications/Message_sequence_for_Zuora_callout_basic_authentication

Yolanda · ‎07-07-2019

After the Preemptive Auth feature has been enabled at the tenant level, you will still need to update the definition of your notifications to make it enabled for the callout you'd like it to work under the preemptive way. Currently, this could only be done through API. Here is the API request to query notification definition: Get a notification definition Here is the API request to update the notification definition: Update a notification definition Here is an example of how to update the preemptive field to true for a notification definition: PUT https://rest.apisandbox.zuora.com/notifications/notification-definitions/14699b88afa012345678a1ebd021b4d3 { "callout": { "calloutAuth": { "preemptive": true, "password": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "username": "xxxx.xxxx@xxxxxx.xxx" } } }

Happy Business Starts Here