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" } } } ... View more

If your environment has Invoice Settlement enabled, the requirement could be met by creating a tax only credit memo(*). And below are the detailed steps of how to do that:   1) open the invoice need to have tax amount credit back 2) click the button more > Create Credit/Debit Memo 3) Click the little icon beside of Invoice Item name, update the credit amount of the invoice item to 0, leave the credit amount of the tax item to the amount you'd like to credit back to the customer. 4) Save and post the credit memo 5) Open the posted credit memo and click the button more > refund this credit memo ... View more

The main difference between these 2 features are:   Supported Features Below features are only supported by v2.0: Level 2 and Level 3 Support for CyberSource Stored Credential Transactions( Visa Stored Credential Transaction ) Ignore AVS Result when Verifying Card Ignore AVS Result during Payment with Card   Configuration When configuring payment gateway instance: v1.97 requires to upload a Simple Order key v2.0 requires to input a SOAP key   This post only lists the major difference between these 2 versions, for detailed configuration information and requirements, please still refer to our Knowledge Center articles. Thanks! CyberSource Payment Gateway Level 2 and Level 3 Support for CyberSource ... View more

A payment method could be closed by different reasons in reality but in Zuora, when a payment method is closed by the payment method updater, the reason is that the payment gateway has returned us a record to let us close the account(close the payment method).   On Zuora side, once the Payment Method Updater is active, there is no option to configure it skip the type of AccountClosed event.   And in many cases, the payment gateway is also known about the real reason why the got an account closed response from the card issuer bank. In most cases, the issue will need to be resolved by the user and their card issuer bank.   But in case the account close is not expected and you'd like to further confirm with payment gateway, here are the steps of how to find the record when the payment method was closed and the data we got from payment gateway.   1) login to your tenant and go to Data Source Export 2) select Payment Method Update as the Data Souce Object 3) select the fields you'd like to check 4) add below filters  Payment Method Update: Billing Account ID = [the owner account id] Payment Method Update: Status = Updated Payment Method Update: Update Type = AccountClosed Then you could share the exported file to payment gateway and highlight the column of Payment Method Update: Retrieve Response Transaction Log and request for further investigation for that. ... View more

0) make sure you've got the latest version of Chase Payment Gateway enabled in your tenant (if not, please contact us at   Zuora Global Support   )   1) Login to your Zuora tenant, goto the payment gateway configuration page, select gateway type Chase Paymentech Orbital Gateway from the dropdown list to create a new gateway instance   2) create a customer account and assign the newly created payment gateway as its payment gateway​ ​ 3) test the related API requests A. creating a profile when creating a Visa payment method  https://www.zuora.com/developer/api-reference/#operation/POST_PaymentMethodsCreditCard Sample Request&Response:   POST https://rest.apisandbox.zuora.com/v1/payment-methods {"accountKey": "2c92c0f86a2f3322016a2f93e0155eeb", "cardHolderInfo": {"addressLine1": "test", "zipCode": "12345", "state": "California", "phone": "1234567890", "country": "USA", "cardHolderName": "test", "city": "test", "email": "test@testaddress.com"}, "expirationMonth": "10", "cardType": "Visa", "type": "CreditCard", "expirationYear": "2029", "cardNumber": "4000000000000002", "securityCode": "123", "makeDefault": "false", "mitProfileAction": "Activate", "mitProfileType": "Recurring", "mitConsentAgreementSrc": "External" } {   "success": true,   "id": "2c92c0fb6b78fe14016b87be21860059" }     B. creating a profile to existing Visa payment method https://www.zuora.com/developer/api-reference/#operation/POST_CreateStoredCredentialProfile Sample Request&Response: POST https://rest.apisandbox.zuora.com/v1/payment-methods/2c92c0f86ab120d4016ab399a607369c/profiles {   "authGateway": "2c92c0f969e32a490169fc07c38d275b",   "consentAgreementRef": "CustomerAgreement.pdf",   "consentAgreementSrc": "External",   "status": "Active",   "type": "Recurring" } {   "success": true,   "paymentMethodId": "2c92c0f86ab120d4016ab399a607369c",   "number": 1 } Here will be how the Visa payment method with profile created looks like: ​     ... View more

Here is a very simple test of using Customized Notification with Workflow to trigger credit balance change email notification. The reason not using email in billing service tenant is because many important merge fields(like CreditBalanceAdjustment.Amount) are not supported by the email notification template but supported by notification callout. And this is a test for the environments which don't have Invoice Settlement enabled.   1. Create Event Trigger https://www.zuora.com/developer/api-reference/#operation/POST_EventTrigger   POST https://rest.apisandbox.zuora.com/events/event-triggers { "baseObject": "CreditBalanceAdjustment", "condition": "changeType == 'INSERT'", "description": "Trigger an event when CreditBalance is created", "eventType": { "name": "CreditBalanceAdjustmentCreated", "displayName": "CBA Created", "description": "CBA Created" }, "active": true }     2. Create Notification 1) login to your billing service tenant, goto Billing Settings > Setup Profiles, Notifications and Email Templates 2) select the Communication Profile you'd like to add the notification and click add new notification 3) select the event trigger name you just created in 1 in the dropdown list of Related Event 4) check on Active, check on Callout, then add callout parameters as below and save (we could put a dummy value for the password and the Base URL here for now)   3. Create Workflow I'll skip the general steps to use workflow and please visit our Knowledge Center to get a more detailed instruction: https://knowledgecenter.zuora.com/CE_Workflow 1) Open your Workflow application, create a new workflow instance 2) Go to the SETTINGS tab and configure the Mapped Input Fields and Params as below (please make sure the order of them is the same as the order of callout parameters in your billing service tenant) 3) Then in the same setting page, copy the URL and password from the Callout Config section after clicking the Show credentials button. 4) Pasting theURL and password back to your callout setting in your billing services tenant(the ones we used a dummy value). 5) Go back to the tab of WORKFLOW, click the plus sign, then On Start > Notifications > Email 6) In the Address tab, configure as how you need the email addresses to be 7) In the Body tab, customize your template using the input parameters. Below is an example of the email body: 8) Give this step a name at the top of the popup and save it.    4. Test 1) login to your billing service tenant, create/find a customer account 2) make sure the customer account is in the Communication Profile where you created the notification 3) click the button process a payment  4) fill in the required info to create a payment, make sure the payment is applied to the account instead of any invoice 5) after the payment is created, go to the customer account page and check the Callout History (from Event Triggers) tab at the bottom of the page 6) goto your Workflow instance to check the RUN HISTORY tab 7) check your email    ... View more

The behavior observed is the expected behavior.   Zuora's callout authentication was implemented following  RFC 2617 and RFC 7235. (the original documentation that defined Basic Auth)   So the Basic Auth follows a "challenge-response" mechanism, which means i t requires the first request to the server to be sent without credentials. After receiving 401 Unauthorized error from the server, a second request should then be sent out with encoded credentials.    So the 401 Unauthorized error you observed are the result of our 1st attempts which were sent without a credential and then the 2nd attempts were sent with credentials so the notification history is showing succeeded results.   (Please be noted that the 1st attempt without a credential and 2nd attempt with credential are 2 separate requests which are considered as 1 attempt visible to the user, which means the 401 error returned for the 1st attempt will not be counted in the Maximum Number of Delivery Attempts configured for Callout Retry rules)   [ref: RFC 2617 Section 1.2 ] ... View more

Since the agreement end users signed/acknowledged will not be sent to Zuora, so if the customer is storing the agreements from end users as any type of data in their own system, they could use field `field_mitConsentAgreementRef` to save an id or any other string to help to link it to Zuora system. (as noted in the document, the id/string should be <= 128 characters). Here are 2 examples of how customer could use it: (Customer: zuora customers, End User: card owners) Example 1: The agreements from end users are being stored as a PDF file(digit copy of the agreement) in customers server under different folders. So the value of `field_mitConsentAgreementRef` could be `Folder: 04122019, File: CustomerName_Agreement_1.PDF` Example 2: The customer is saving a record in their database every time there is an end user acknowledges the agreement. The record has all necessary information about the agreement(e.g. end user id, acknowledged datetime, agreement type...) So the value of `field_mitConsentAgreementRef` could be the id of the record in your database like `kQNsmpIhsXsCONBGHypKttuT` ... View more